Перейти к содержимому


Фотография

Жуткие тормоза форума после обвноления с 2.1.7 до 2.2.2

Форумы IBResource

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 62
MIl
  • Участники
  • Cообщений: 11

Отправлено

Хочу поделиться моей печальной историей по переходу с 2.1.7 на 2.2.2.

Имеется:
- выделенный сервер под форум - P4 3.2Ghz, RAM 2GB, 2 разных винта с разнесёнными по ней некоторыми таблицами базы и сайтом. FreeBSD 6.2, MySQL 4.1.22 (libthr), php 4.4.4 (apache2handler).
- форум версии 2.1.7 c примерно 500 посетителей за 15 минут в рабочее время и вот такой прочей статистикой:
На форуме сообщений: 1748011
Зарегистрировано пользователей: 10775
Рекорд посещаемости форума - 1063, зафиксирован - 19.6.2006, 15:29


Сам процесс обновления проходил достаточно спокойно. Была одна заморочка со стилями - хотя я и указал инсталлятору, что можно удалить всё что ему вздумается, но после установки оказалось, что, ни старые, ни новые стили нормально не отображались - почти все управляющие надписи отсутствовали.
Я потратил часа полтора-два на эту проблему. Пришлось поставить на другой машине новую версию на чистую и импортнул оттуда стиль на боевой сервер, но это проблемы не решило. А решило проблему импортирование русского языка с чистой инсталляции.
Естесственно я перед обновлением удалил со старой версии всё, кроме конфига и аплоадов. Вероятно инсталлятор создал новый набор на основании старых данных из БД, а больше им взяться было неоткуда.


Ещё одна заморочка, которая не имеет прямого отношения к движку, но которая теоритически могла в какой-то мере повлиять на работу форума после обновления, это путаница с кодировками.
Исторически так получилось, что у меня и скрипты и база были в кои8р, т.к. так проще работать со скриптами и базой из юниксовой консоли. Ну а так как русифицированный форум поставлялся в кондировке цп1251, то каждый раз перед обновлением мне приходилось переконвертить скрипты в кои8р.
В этот раз я решил оставить срипты в цп1251, а базу в кои8р, потому привести их к одной и той же кодировке было затруднительно. В принципе мне это удалось, за несколькими исключениями из АдминПанели, которые мне пришлось перекодировать вручную и перезалить в БД.
Эту заморочку я описываю потому, что допускаю, что перекодировка данных в и из БД занимала некоторые ресурсы сервера.


В самом конце обновления инсталлятор порекомендовал обновить информацию о сообщениях и аттачментах через АдминПанель. И, хотя с виду с сообщениями было всё нормально, я запустил этот процесс. Но его пришлось прервать, т.к. он проходил чрезвычайно медленно - за 2-3 часа было обратано не более 200 тысяч из почти 1,7 млн. сообщений. Это тоже теоритически могло повлиять на скорость работы форума.


После запуска форума в работу появились настоящие проблемы - при нагрузке раза в 2-3 меньше обычной форум жутко тормозил, а система была загружена выше всяких разумных пределов. В юниксах есть такое понятие как LoadAverage - количество процессов, ожидающих получения ресурсов системы. В нормальном случае этот показатель не должен быть больше единицы. На моём сервере LA со старой версией в пиках достигал и 10-ти, а обычно был меньше 5-ти, причём это было ещё снижение после массы танцев с бубеном вокруг системы.
Так вот, LA на той же системе с новым движком весь день колебалась между 30-тью и 50-тью! Ну и о нормальной работе с форумом конечно речи не было.
Судя по всему MySQL просто перестал справляться с новой нагрузкой, о чём свидетельствовало почти постоянный длинный список процессов СУБД.
Всё остальное, включая MySQL, осталось тоже самое, так что под подозрением оставался только новый движок.

И вот из старых копий, сделанных перед обновлением, всё было возвращено обратно, завелось с пол-пинка и просто летает.
Несмотря на то, что у нас уже почти восемь часов вечера на форуме больеш 300 человек и тот самый LA колеблется между 2-мя и 4-мя, т.е. при примерно том же количестве посетителей в онлайне нагрузка системы со старым движком на порядок меньше.


Вот такая история. Я уже назвал все свои действия, которые теоритически могли привести к описанной ситуации, но хотелось бы знать наверняка где я накосячил.

Сообщение отредактировал MIl: 05 Март 2007 - 17:14


archtod
  • Участники
  • Cообщений: 165

Отправлено

вполне возможно - у мя нагрузка тоже увеличилась стабильно.

Большая часть нагрузки идет на процессор около 10 единиц,а было макс 5.

MIl
  • Участники
  • Cообщений: 11

Отправлено

То что новый движок с кучей новых фич требует больше ресурсов это понятно. При переезде с 1.3 на 2-ю версию нагрузка возрасла, но осталась допустимой. А тут...
Мне просто важно выяснить для себя что это было - проблема, вызванная некими неправильными действиями по обновлению, или это вовсе и не проблема, а закономерный результат работы нового движка.

nasdef
  • Участники
  • Cообщений: 19

Отправлено

Тоже выросла нагрузка процентов на 30-50

Master
  • Участники
  • Cообщений: 3 051
  • Город:Чебы

Отправлено

Форум немного тяжелее стал.
Попробуйте кеширование включать.
Документация на Invisionpower.

der Panter
  • Участники
  • Cообщений: 63

Отправлено

да... не ожидал я что на столько хуже станет...

Похоже останусь на "старом" движке, апгрэйдить сервер из-за форума в котором добавили кучу ненужных фич нецелесообразно.

Кстати, Master, а нет ли у инвижена или у вас какого-нибудь инструмента, который смог бы смоделировать нужную нагрузку на сервер. Просто не очень понятно из чего исходить рассчитывая конфигурацию сервера для инвижена.

Denny
  • Участники
  • Cообщений: 245
  • http://

Отправлено

MIl, с такой крупной базой не думали о отдельном БД-сервере? Так же о перспективе перехода на PostgreSQL или Oracle. Postgre даёт прирост производительности (отчётливо заметно на огромных форумах), а с Oracle ещё не возился.

P.S. семейство 2.2 пожирнело, так что будем ждать решений от производителя.
P.P.S. не встречал утилит для моделирование нагрузки от IP.B, но утилиты для моделирования нагрузки на сервер существуют :D

MIl
  • Участники
  • Cообщений: 11

Отправлено

Master

Попробуйте кеширование включать.

О каком именно кешировании вы говорите? В самом движке?
PHP-кеш у меня стоит - Turck MMCache.


MIl, с такой крупной базой не думали о отдельном БД-сервере? Так же о перспективе перехода на PostgreSQL или Oracle. Postgre даёт прирост производительности (отчётливо заметно на огромных форумах), а с Oracle ещё не возился.


Об отдельном БД-сервере думал, вопрос в деньгах, которых хватит на такую машинку, которая, уверен, проблему не решит. Если движок в состоянии так легко загрузить указанную мной машину, то мне нужно что-то с 4-мя процами, 4 гигами ОЗУ и сказёвым раид массивом, что-бы форум нормально работал ещё хоть с годик )
Ну да ладно, это уже лирика )


Насчёт Постгре. Самое большое что меня беспокоит это необходимость конвертирования базы, а такая необходимость как мне кажется есть. Интересно знать сколько будет конвертиться таблица ibf_posts c более чем 2 млн. записей?
Также беспокоит небольшая популярность Постгре для ИПБ, это вполне логично наводит на мысли о худшей поддержке и меньшей отлаженности.


Подводя итог скажу, что на данный момент я принял решение оставаться на версии 2.1.7 до тех пор пока не будут найдены ресурсы на сервер, на много превосходящий существующий по производительности.

MIl
  • Участники
  • Cообщений: 11

Отправлено

Интересное дополнение.
Только сейчас обратил внимание на график количества операций чтения с дисков. По нему видно, что во время работа форума на версии 2.2.2, кроме loadaverage сильно выросло и кол-во операций чтения с дисков. А точнее их стало раз в 5 больше, чем обычно.
При этом на графике операций записи на винты заметного роста нет, за исключением пары непродолжительных пиков.

Т.к. на втором винте (SATA) у меня только БД, получается, что скорее всего мускл тормозил просто из-за большого кол-ва чтений из базы, которые винт просто не успевал обслужить. Отсюда напрашивается вывод, что в новой версии сильно выросло кол-во обращений к базе.

Denny
  • Участники
  • Cообщений: 245
  • http://

Отправлено

Об отдельном БД-сервере думал, вопрос в деньгах, которых хватит на такую машинку, которая, уверен, проблему не решит. Если движок в состоянии так легко загрузить указанную мной машину, то мне нужно что-то с 4-мя процами, 4 гигами ОЗУ и сказёвым раид массивом, что-бы форум нормально работал ещё хоть с годик )Ну да ладно, это уже лирика )

Т.к. на втором винте (SATA) у меня только БД, получается, что скорее всего мускл тормозил просто из-за большого кол-ва чтений из базы, которые винт просто не успевал обслужить. Отсюда напрашивается вывод, что в новой версии сильно выросло кол-во обращений к базе.

Вот Вам и вывод - не ОЗУ увеличивать надо, а менять винт (на SCSI или Ultra SCSI). Мне вообще удивительно, почему с таким объёмом ОЗУ тормоза.

Насчёт Постгре. Самое большое что меня беспокоит это необходимость конвертирования базы, а такая необходимость как мне кажется есть. Интересно знать сколько будет конвертиться таблица ibf_posts c более чем 2 млн. записей?Также беспокоит небольшая популярность Постгре для ИПБ, это вполне логично наводит на мысли о худшей поддержке и меньшей отлаженности.

Во-первых, постгре официально поддерживается IPS, поэтому проблем с переходом/конвертацией/поддержкой не будет (у меня во всяком случае не было). Единственный минус - это проблемы с некоторыми модами/модулями/компонентами.

Мастер говорил про кэширование в IP.B

Vic'er
  • Участники
  • Cообщений: 1 212
  • http://team-madalf.com/
  • Город:Киев, Украина

Отправлено

мну-мну.... интересная инфа, спасибо...

тоже подумывал перейти, но теперь даже не знаю...

а насчет увеличения обращений к ФС - могу предположить, что это юзается модуль кеширования, так как если нет проинсталленых мемкешей то кеширование идет на диск.

Postgre даёт прирост производительности

вот уж не уверен, на одном крупном проекте (не форум) думаю избавляться от постгреса и переводить его на мускуль, так как постгрес тормоз еще тот ((((

GiV
  • Участники
  • Cообщений: 5 513
  • http://www.wtf.sh/
  • Город:да

Отправлено

MySQL настроен не правильно + на больших форумах надо использовать реально другие механизмы поиска (см. в клиентских разделах)
Apache надо менять реально на другой сервер, PHP запускать в FastCGI.

По нагрузке измениться ничего не должно кроме того, что добавлено много JavaScript + AJAX.

Kolovrat
  • Клиенты
  • Cообщений: 401
  • http://kolovrat.tv
  • Город:Западная Сибирь, г.Омск

Отправлено

... думаю избавляться от постгреса и переводить его на мускуль, так как постгрес тормоз еще тот ((((

Совершенно с тобой согласен. Постгри тормоз еще тот.
Поэтому я с него перешел на муслика. Правда тут есть одна проблема.
Конвертеров перегоняющих из муслика в постгри полно, а вот для обратного перегона из постгри в муслика я так и не нашел... поэтому пришлось всю БД переписывать вручную.

Denny
  • Участники
  • Cообщений: 245
  • http://

Отправлено

Ну да, Postgre тормознутее MySQL... Во-первых он более стабилен, во-вторых более функционален, в-третьих чувтствуется разница между PostgreSQL и MySQL тяжёлых БД (личный опыт + результаты тестирований других программистов/специалистов).

archtod
  • Участники
  • Cообщений: 165

Отправлено

MySQL настроен не правильно + на больших форумах надо использовать реально другие механизмы поиска (см. в клиентских разделах)
Apache надо менять реально на другой сервер, PHP запускать в FastCGI.

По нагрузке измениться ничего не должно кроме того, что добавлено много JavaScript + AJAX.


GIV прав :D) вся нагрузка идет на базу - как раз таки изза AJAX запросов - и вообще аякс сам по себе базу сильно грузит - а в новой версии его просто немеряно.

А насчет пхп в фастцги хорошая идея ;) а вообще надо связку nginx+apache ставить :)

Denny
  • Участники
  • Cообщений: 245
  • http://

Отправлено

Возможно, GiV и прав, но в его посте не говорится о нагрузке на БД из-за AJAX. AJAX вообще к БД никакого отношения не имеет, мат.часть учите

archtod
  • Участники
  • Cообщений: 165

Отправлено

Возможно, GiV и прав, но в его посте не говорится о нагрузке на БД из-за AJAX. AJAX вообще к БД никакого отношения не имеет, мат.часть учите


Хаха ну ты конечно дал :D

а как ты думаешь идет через аякс добавление комментов, изменения настроек, а так же отображение в профиле последних постов? еще быстрая редакция поста?

Все это идет обращение к базе через аякс, а если на форуме 50 человек сидит и 10 из них просматривают профили - добавляют коменты, редактируют. Достаточно много получается.

а посчитай для форумов где 1000 людей сидят.

И это еще не считая обычных запросов к базе.

Так что можешь смело идти в гугл и спросить что такое аякс для начала ;)

Valera

    IBR Team

  • Участники
  • Cообщений: 1 548
  • http://smbb.ws
  • Интересы:[url=http://smbb.ws/]форум на smarty[/url]

Отправлено

не говорится о нагрузке на БД из-за AJAX

Потому что сам, в смысле основной скрипт форума тоже создает нагрузку, в связи с чем глупо писать что грузит сервер баз данных, только аякс.

>Все это идет обращение к базе через аякс, а если на форуме 50 человек
>сидит и 10 из них просматривают профили - добавляют коменты,
>редактируют. Достаточно много получается.

Ты забыл еще подсчитать процессы апача которые в купе с модулями, съедают чуть ли не всю оперативку(резко падает эффективность кеша, память "уходит" в своп). Кто-то уже писал, что в 2.2.2 резко увеличился объем файловых операций! А почему, ответ очевиден...

archtod
  • Участники
  • Cообщений: 165

Отправлено

не говорится о нагрузке на БД из-за AJAX

Потому что сам, в смысле основной скрипт форума тоже создает нагрузку, в связи с чем глупо писать что грузит сервер баз данных, только аякс.

>Все это идет обращение к базе через аякс, а если на форуме 50 человек
>сидит и 10 из них просматривают профили - добавляют коменты,
>редактируют. Достаточно много получается.

Ты забыл еще подсчитать процессы апача которые в купе с модулями, съедают чуть ли не всю оперативку(резко падает эффективность кеша, память "уходит" в своп). Кто-то уже писал, что в 2.2.2 резко увеличился объем файловых операций! А почему, ответ очевиден...


а я и не говорил что только аякс грузит, это и ежу понятно, что кроме яакса на форуме еще много чего :D просто в отличие от 2.1. в 2.2. яакса на порядок больше ;)

А насчет апача который съедает оперативу это уже зависит от настроек самого апача и PHP :) мона его таким жирным собрать, что тебе и всех 4гигов оперативы не хватит.
А можно с минимумов жирностей - когда у мя был слабый сервак - пхп у мя был как модуль апача и на минимуме чисто поддержка мускула и то что надо для намано работы форума - и ничего все было оке.
Щас сервер по-мощнее и пхп как cgi стоит и всяких модулей дохера, да и к тому же мемори лимит 32 метра и ничего :)

кстати никто не пробовал в 2.2. профили сделать классического вида и посмореть как с нагрузкой?
просто достаточно много на этот новый профиль уходит :)

Song
  • Участники
  • Cообщений: 9 552
  • http://www.sysman.ru
  • Город:Кострома
  • Интересы:Программирование, плаванье

Отправлено

а как ты думаешь идет через аякс добавление комментов, изменения настроек, а так же отображение в профиле последних постов? еще быстрая редакция поста?Все это идет обращение к базе через аякс, а если на форуме 50 человек сидит и 10 из них просматривают профили - добавляют коменты, редактируют. Достаточно много получается.



но всё же это меньше нагрузки, чем если бы всё тоже самое юзеры делали не через ajax интерфейс.
К примеру, редактирование сообщений.
Если бы редактирование было обычным, то к редактированию добавляется ещё перечитывание текущей страницы топика.




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных