Перейти к контенту
  • 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
все настройки клепались в 1 массив и записывались в 1 файл.

бугага

 

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

подождите, почему?

 

сейчас работает так:

загружается список всех параметров,

потом в цикле - запрашивается файл кеша настройки для этого параметра, потом unserialize, потом полученное пишется в массив $ipsclass->vars

и так каждая настрйока, отедльным файлом.

Почему бы это все не писать в 1 файл и вместо цикла делать 1 действием?

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

  • 0

Большое количество операции не обязательно хуже чем одна.

 

В вашем случае php станет кушать больше памяти (http://doughboy.wordpress.com/2007/02/28/big-arrays-in-php/)

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

  • 0

дык в любом случае на выходе получается один и тот же массив,

или я чего в механизме 2.2.х ещё не до конца понял? как я это вижу - так или иначе на выходе получаем массив, один и тот же. Так легче срау его хранить в 1 файле и собрать 1 действием чем инклудить десятки кешированных файлов и собирать все тот же массив.

 

кстати, я предлагаю пистаь в кеш serialize'ed массив всех настроек, а не сам массив, конечно,

т.е.

<?

$var['key'] = ['val'];

...

?>

я не предлагаю

 

 

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

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

  • 0

Работа с файловой системой медленнее чем с БД.

Теперь представляем что у вас 500 обращений в секунду (500 пользователей в онлайн). Вы гарантируете что Ваша система будет вести себя так же быстро?

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

  • 0

А кто сказал что он используется?

 

Дисковый кэш используется как правило при разработке и отлова багов, но никак не на прод-серверах. Для нормального кэширования существуют другие решения: Turck-MMCache, XCache, etc.

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

  • 0
А кто сказал что он используется?

 

Дисковый кэш используется как правило при разработке и отлова багов, но никак не на прод-серверах. Для нормального кэширования существуют другие решения: Turck-MMCache, XCache, etc.

неправда :D вот последовательность обработки

 

init_cache_setup()

 

если есть Eaccelerator и он позволен, то он{

...

}

//ниже тупизм или баг, пропущено иначе

если есть Turck-mmcache и он позволен, то он {

...

}иначе если есть Memcache и он позволен, то он {

...

}иначе если есть XCache и он позволен, то он {

...

}иначе если есть APC и он позволен, то он {

...

}иначе если позволен Diskcache, то он {

...

}

 

как видим, Diskcache будет юзаться всегда, если нет ни Turck-mmcache, ни Memcache, ни XCache, ни APC. В случае же если есть Eaccelerator и позволен Diskcache, то Eaccelerator НИКОГДА НЕ БУДЕТ ЗАДЕЙСТВОВАН

 

В вашем случае php станет кушать больше памяти (http://doughboy.wordpress.com/2007/02/28/big-arrays-in-php/)

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

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

  • 0
Дисковый кэш используется как правило при разработке и отлова багов, но никак не на прод-серверах. Для нормального кэширования существуют другие решения: Turck-MMCache, XCache, etc.

 

Не совсем согласен, так как производительность современных дисковых кешей (рам диск например) доходит до 8гб в сек.... :D Что майскуэл, например на скази дисках, такая производительность(простейшие селекты) не будет снится еще в ближайшие 1000 лет. ;):):) К тому же сам mysql юзает файлы.

Хранение объектов на рам-дисках уже активно используется (помоему уже полгода), например в vbulletin (там есть что-то типа драйвера).

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

  • 0

Блин, поставил вчера 2.2.2 (до этого вообще не юзал IPB в роли владельца). Он что, намного сильнее напрягает машину чем 2.2.1?

Он у меня на виртуальном хосте стоять будет пока что, может мне поставить 2.2.1 пока я моды не начал еще ставить или вообще 2.1.***?

Дайте добрый совет плиз :D

Сорри что в чужом топике, просто смотрю тут как раз и 2.1. затронуты и 2.2 ;)

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

  • 0

2 Chin,

думаю, Вам пока что не стоит заморачиваться затрагиваемыми в этой теме вопросами (хотя может быть я и ошибаюсь в размерах Вашей борды)

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

  • 0

Garret, именно так :D

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

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

  • 0
иначе если позволен Diskcache, то он

он позволен по-умолчанию?

 

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

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

 

Не совсем согласен, так как производительность современных дисковых кешей (рам диск например) доходит до 8гб в сек....

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

 

К тому же сам mysql юзает файлы.

Да вообще то все БД используют файлы, ага. Но если этот факт относится к процессу работы mysql при выборках например, т.е. при селктах mysql активно использует файлы, то перед словом 'mysql' стоит поставить - не правильно настроенный.

 

Хранение объектов на рам-дисках уже активно используется (помоему уже полгода), например в vbulletin (там есть что-то типа драйвера).

дисковый кэш там точно был, если рам диск для системы представляется аналогом обыкновенного, то и IPB так же работает.

 

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

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

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

  • 0

Я "дружу" с суппортом хостера и не хочу создавать проблем излишней нагрузкой. За это суппорт меня тоже любит и помогает с вопросами, с которыми помогать не обязан. Расстреливать меня никто не будет. А вот чтобы небыло процессов, которые надо убивать (и "письма клиенту") я и спрашиваю намного ли он сильнее напрягает сервер чем 2.1.* ;)

Ну или скажем так: стОят ли фичи, добавленые в 2.2.2 того увеличения нагрузки, которое будет по сравнению с 2.1.*.

Спрашиваю в первую очередь у представителей ИБР, кому как не вам это знать :D

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

  • 0
стОят ли фичи, добавленые в 2.2.2 того увеличения нагрузки, которое будет по сравнению с 2.1.*.

Если Вы за удобство пользователей - несомненно стоит.

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

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

  • 0

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

Как я понял, в случае с несколькими десятками/сотнями пользователей (всего, а не единовременно) у меня не будет особых трудностей на виртуальных хостах. Если это так - всё понял. Спасибо за ответ :D

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

  • 0

если всего пару сотен то никаких траблов :D)

 

нагрузка пропорционально растет если боль50-100 юзеров одновременно ;))

 

благо у мя один сервак на один проект :)) держится запросто

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

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

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

 

Про "другие механизмы поиска" сейчас поищу информацию.

Насчёт Апача. Пробовал nginx и php как fastcgi - не работало быстрое редактирование сообщений (а может и ещё что-то), пришлось отказаться. Попробую ещё раз.

Кстати, все картинки и аплоады раздаются nginx-ом, который висит на дополнительном айпишнике на этом же сервере.

 

Мускл настроен неправильно? Допускаю. Тогда скажите что именно неправильно.

 

mysql41-server собран из портов:

WITH_CHARSET=koi8r WITH_COLLATION=koi8r_general_ci \

WITH_LINUXTHREADS=yes WITH_PROC_SCOPE_PTH=yes \

BUILD_OPTIMIZED=yes BUILD_STATIC=yes \

make install

 

В файле /etc/libmap.conf указан маппинг:

liblthread.so.3 libthr.so.2

 

В стандартном /etc/my.cnf изменены следующие опции:

max_connections=300

skip-locking

skip-external-locking

skip-innodb

key_buffer = 384M

max_allowed_packet = 1M

table_cache = 512

sort_buffer_size = 24M

myisam_sort_buffer_size = 24M

read_buffer_size = 2M

read_rnd_buffer_size = 8M

thread_cache_size = 38

query_cache_size = 16MB

tmp_table_size = 32MB

record_buffer = 4M

net_buffer_length = 16K

wait_timeout=60

interactive_timeout=60

flush_time=3600

 

Все файлы с базой находятся на втором диске, кроме файлов ibf_topic_markers.MYD и ibf_topic_markers.MYI, которые, для более равномерного использования дисков, перенесены на первый диск.

Все таблицы в MyISAM, кроме ibf_sessions - она в HEAP.

 

Какая информация ещё нужна?

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

  • 0

Ищу решение проблемы для 2.2.2.

 

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

 

Форум находится на хостинге мажердома.

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

  • 0
хм.. Наверное завести отдельной маской и запретить использовать поиск, просмотр профилей, и все по максимуму. оставив только просмотр тем и сообщений.
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Пробовал nginx и php как fastcgi - не работало быстрое редактирование сообщений (а может и ещё что-то), пришлось отказаться. Попробую ещё раз.

http://dev.iblinik.ru/2.2.x/

 

nginx + php fastcgi - полет нормальный во всем. Включайте лог и смотрите ошибки.

 

Про "другие механизмы поиска" сейчас поищу информацию.

С клиентского раздела начинайте про методики оптимизации MySQL.

 

Конфиг mysql интересный, но для каждого форума он специфический. Смотреть надо "медленные" запросы, и состояние буферов.

 

Выигрыш при сборке Mysql с тредами под БСД спорен =) даже при таком маппинге.

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

  • 0
хм.. Наверное завести отдельной маской и запретить использовать поиск, просмотр профилей, и все по максимуму. оставив только просмотр тем и сообщений.

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

Вопрос же был поставлен - Как сделать так, чтобы они не тормозили форум?

Ведь на 2.1.6 таких тормозов небыло...

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

  • 0

Kolovrat, то, что написали о запрете индексации профилей и поиска - это абсолютно правильно тебе написали.

И регулировать это можно с помощью robots.txt

Что касается гугля - ему можно указать интенсивность траханья твоего форума. Ну а если в индекс яндекса попадут результаты поиска на твоем форуме (особенно если много их проиндексируется) - тебя могут вообще из базы выкинуть.

Могу прикинуть примерное решение - по рефереру и ИП определять, не бот ли влез на форум, и если бот - с помощью например мод-реврайта отдавать ему другой скин, который делает меньше запросов к базе.

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

  • 0
Могу прикинуть примерное решение - по рефереру и ИП определять, не бот ли влез на форум, и если бот - с помощью например мод-реврайта отдавать ему другой скин, который делает меньше запросов к базе.

за такую хрень могут забанить.

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

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

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

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

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

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

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

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

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

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

Зарузка...

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

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

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