Перейти к контенту
  • 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

Song, ничего подобного. Забанят если подменять сам контент. Я не про клоакинг для ботов с целью улучшения позиций говорю, а про клоакинг ОБЛЕГЧАЮЩИЙ скачиваемый ботом контент.

Конечно если менять текст сообщений, добавлять/убирать внешние ссылки и т.п. - могут забанить. Так я ж не это советую делать :D

Так что никакого криминала, можете сами поинтересоваться у Яндекса (только вопрос развернуто опишите, там не телепаты работают)

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

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

А обязательно так всё через ж**у делать? :D

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

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

  • 0

Я тебя огорчу - это неполноценный метод. Во первых есть хитрые боты (и у гугла и у яндекса). Во вторых некоторые боты не отдают признаков и ходят с сетей "неофициальных". В достаточно большом кол-ве. И рефереры меняют туда-сюда, какие хочешь, куки жрут и т.д. Вся эта инфа есть в сети достаточно давно.

Так что если хочется полноценного решения - всё таки клоакинг имхо.

Разумеется придется соблюдать свежесть баз ИПшек ботов.

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

  • 0

Господа, столкнулся с похожей (или даже) худшей проблемой. 2.2.х форум не просто грузит процессор - куда-то постоянно утекает память.

 

За два часа форум с посещаемостью 1700 хитов в сутки вываливает в даун хостинг сервер. Dual Xeon, 2GB RAM. В топе основную нагрузку создаёт Мускул и кушает 400 МБ оперативки, остальная память уходит куда-то налево в итоге когда размер Inactive memory превывает допустимые пределы, кушается своп и в конце концов сервак виснет.

 

Думали проблема в Мускуле + ПХП 4тых версий. Обновили ПХП до 5той - не помогло. Отключили всё что можно. Ещё правда не пробовали залить файлы по новой (чтобы избежать влияния модов и скинов) и не обновили Мускул до 5той версии.

 

К тому же непонятно, что за скрипт это делает. Не подскажите как отмониторить путь к скрипту, из-за которого происходит этот memory leak? Как понять куда и почему девается память... Раньше стоял 2.1.7 таких проблем не возникало...

 

Скажите, нормальны ли следующие характеристики для вышеописанного хостинг-сервера и форума с 1700 хитами в сутки (10000 зарегестрированых пользователей):

 

Я сравникаю с IBResource и кое где опережаю, кое где отстаю (Gzip on):

 

главная страница - 0.05-0.06 sec -- 7 queries

раздел (список топиков) - 0.08-0.12 sec -- 8 queries

тема - 0.12-0.15 sec -- 11 queries

 

самая большая нагрузку на тему (и это при том, что я всё вырубил в CPU Saving)

 

что в ниже приведённом срезе SQL дебага темы есть лишним запросом не подскажите?

 

SELECT * FROM ibf_topics WHERE tid=30146 SELECT * FROM ibf_cache_store WHERE cs_key IN ( 'attachtypes','bbcode','multimod','ranks','profilefields','rss_calendar','rss_export','components','banfilters','settings','group_cache','systemvars','skin_id_cache','forum_cache','moderators','stats','languages' ) 

SELECT id, member_id, running_time, location FROM ibf_sessions WHERE id='ХХХ' AND ip_address='ХХХ' 

SELECT id, name, mgroup, member_login_key, member_login_key_expire, email, restrict_post, view_sigs, view_avs, view_pop, view_img, auto_track, mod_posts, language, skin, new_msg, show_popup, msg_total, time_offset, posts, joined, last_post, subs_pkg_chosen, ignored_users, login_anonymous, last_visit, last_activity, dst_in_use, view_prefs, org_perm_id, mgroup_others, temp_ban, sub_end, has_blog, has_gallery, members_markers, members_editor_choice, members_auto_dst, members_display_name, members_created_remote, members_cache, members_disable_pm FROM ibf_members WHERE id=1 

SELECT * FROM ibf_skin_sets WHERE set_skin_set_id=35 

SELECT * FROM ibf_skin_templates_cache WHERE template_set_id=35 AND template_group_name IN ('skin_global', 'skin_topic') 

SELECT * FROM ibf_topic_ratings WHERE rating_tid=30146 and rating_member_id=1 

SELECT * FROM ibf_topic_markers WHERE marker_forum_id=2 AND marker_member_id=1 

SELECT pid,topic_id FROM ibf_posts WHERE topic_id=30146 ORDER BY pid asc LIMIT 40,20 

SELECT p.*, pp.*, m.id,m.name,m.mgroup,m.email,m.joined,m.posts, m.last_visit, m.last_activity,m.login_anonymous,m.title,m.hide_email, m.warn_level, m.warn_lastwarn, me.msnname,me.aim_name,me.icq_number,me.signature, me.website,me.yahoo,me.location, me.avatar_location, me.avatar_type, me.avatar_size, m.members_display_name FROM ibf_posts p LEFT JOIN ibf_members m ON (m.id=p.author_id) LEFT JOIN ibf_profile_portal pp ON (m.id=pp.pp_member_id) LEFT JOIN ibf_member_extra me ON (me.id=m.id) WHERE p.pid IN(305375,305393,305429,305436) ORDER BY pid asc SELECT * FROM ibf_skin_templates_cache WHERE template_set_id=35 AND template_group_name='skin_profile'

SHUTDOWN: UPDATE ibf_sessions SET member_name='ХХХ',member_id=1,member_group=4,login_type=1,running_time=1174390973,location='st',in_error=0,location_1_type='topic',location_1_id=30146,location_2_type='forum',location_2_id=2,location_3_type='',location_3_id=0 WHERE id='ХХХХХХХХ'

SHUTDOWN: INSERT INTO ibf_topic_views (views_tid) VALUES(30146)

SHUTDOWN: UPDATE ibf_topic_markers SET marker_unread=7,marker_topics_read='a:2:{i:30635;i:1174381833;i:30146;i:1174390973;}',marker_last_update=1174390973 WHERE marker_member_id=1 AND marker_forum_id=2

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

  • 0
Radar база большая?

 

<200MB

 

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

 

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

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

  • 0

//МНУ СТАВИЛ РЕЛИЗ IPB 2.2.2

 

Алгоритм решения проблем с тормозами 2.2.2 :

 

1. оптимизация и быстродействие в ACP (главная страница 7 запросов, категория 8 запросов, тема 10 запросов)

2. включить кэширование календаря.

3. отключить полностью индексацию форума поисковиками.(если поможет, сделать частичную индексацию)

 

4. CPU limit(еще не пробывал)

5. PHP memory size(еще не пробывал)

6. Перейти на 2.3.1 (реально меньше нагрузка будет?)

 

Alter:

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

 

на shared hosting обычно стоят параметры около:

5-10% CPU,

не более 8Мб Ram на скрипт,

не более 30 секунд на выполнение скрипта.

 

какие требования для хостинга для IPB 2.2.2 ?

 

 

 

проблема на masterhost одна

memory_limit=10MB на начальных тарифах..

 

говорят что при этом работать 2.2.2 не будет нормально ((((((

 

- Когда количество сообщений на Вашем форуме перевалит за 5.000, с 10 мегабайтами выделяемой памяти большинство ресурсоёмких инструментов админцентра не будут работать — будет возвращаться белая страница

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

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

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

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

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

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

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

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

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

Зарузка...

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

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

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