Перейти к контенту
  • 0

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


MIl

Вопрос

Хочу поделиться моей печальной историей по переходу с 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
Ссылка на комментарий
Поделиться на других сайтах

  • Ответы 62
  • Создана
  • Последний ответ

Лучшие авторы в этом вопросе

Лучшие авторы в этом вопросе

  • GiV

    GiV 10 публикаций

  • Chin

    Chin 8 публикаций

  • archtod

    archtod 6 публикаций

  • MIl

    MIl 5 публикаций

Рекомендуемые сообщения

  • 0

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

 

P.S. семейство 2.2 пожирнело, так что будем ждать решений от производителя.

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Master

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

О каком именно кешировании вы говорите? В самом движке?

PHP-кеш у меня стоит - Turck MMCache.

 

 

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

 

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

Ну да ладно, это уже лирика )

 

 

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

Также беспокоит небольшая популярность Постгре для ИПБ, это вполне логично наводит на мысли о худшей поддержке и меньшей отлаженности.

 

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Интересное дополнение.

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

 

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

 

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

 

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

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

Apache надо менять реально на другой сервер, PHP запускать в FastCGI.

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

Совершенно с тобой согласен. Постгри тормоз еще тот.

Поэтому я с него перешел на муслика. Правда тут есть одна проблема.

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

Ссылка на комментарий
Поделиться на других сайтах

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

  • 0
MySQL настроен не правильно + на больших форумах надо использовать реально другие механизмы поиска (см. в клиентских разделах)

Apache надо менять реально на другой сервер, PHP запускать в FastCGI.

 

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Возможно, GiV и прав, но в его посте не говорится о нагрузке на БД из-за AJAX. AJAX вообще к БД никакого отношения не имеет, мат.часть учите
Ссылка на комментарий
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

>Все это идет обращение к базе через аякс, а если на форуме 50 человек

>сидит и 10 из них просматривают профили - добавляют коменты,

>редактируют. Достаточно много получается.

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

>Все это идет обращение к базе через аякс, а если на форуме 50 человек

>сидит и 10 из них просматривают профили - добавляют коменты,

>редактируют. Достаточно много получается.

 

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

 

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

 

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

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

Щас сервер по-мощнее и пхп как cgi стоит и всяких модулей дохера, да и к тому же мемори лимит 32 метра и ничего :)

 

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

просто достаточно много на этот новый профиль уходит :)

Ссылка на комментарий
Поделиться на других сайтах

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

 

 

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

К примеру, редактирование сообщений.

Если бы редактирование было обычным, то к редактированию добавляется ещё перечитывание текущей страницы топика.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

archtod, так чем собственно AJAX грузит БД? :D Я бы вам посоветовал посмотреть, что такое "AJAX". IP.B написан на PHP и "грузит БД" именно php'шные скрипты форума.

 

Согласен с Song'ом. AJAX во многом уменьшает нагрузки IP.B на сервер, но при этом его обилие повышает требования к машине пользователя.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
archtod, так чем собственно AJAX грузит БД? :D Я бы вам посоветовал посмотреть, что такое "AJAX". IP.B написан на PHP и "грузит БД" именно php'шные скрипты форума.

 

Согласен с Song'ом. AJAX во многом уменьшает нагрузки IP.B на сервер, но при этом его обилие повышает требования к машине пользователя.

 

если на то пошло, то бд грузит не пхп скрипты, а запросы к базе, которые создают пхп скрипты ;)

аякс тоже создает запросы к базе :)

еще на лету создает XML данные и кучу всякого барахла.

 

каким это образом он повышает требования к машине юзера? :)

Ссылка на комментарий
Поделиться на других сайтах

  • 0

народ, дак что советуете - попридержаться пока от использования 2.2.2?

 

кстати по поводу дискового кеширования - не пойму зачем там каждая отделньая настройка кешируется в один файл? если буду использовать 2.2.2 то перепишу так чтобы все настройки клепались в 1 массив и записывались в 1 файл.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
еще на лету создает XML данные и кучу всякого барахла.

ну это уже головная боль вашего браузера.

Форум и знать не знает о каких-либо XML.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
все настройки клепались в 1 массив и записывались в 1 файл.

бугага

 

и получите еще больший минус в производительности.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Согласен с Song'ом. AJAX во многом уменьшает нагрузки IP.B на сервер, но при этом его обилие повышает требования к машине пользователя.

Не всякий.

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

Ссылка на комментарий
Поделиться на других сайтах

Присоединиться к обсуждению

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

Гость
Ответить на вопрос...

×   Вы вставили отформатированный текст.   Удалить форматирование

  Допустимо не более 75 смайлов.

×   Ваша ссылка была автоматически заменена на медиа-контент.   Отображать как ссылку

×   Ваши публикации восстановлены.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

Зарузка...

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.