Анализ графиков загрузки и оптимизация web-сервера?

Question

[Павел Вирский]

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

Предыстория: достался в наследство один сайт, расположенный на достаточно мощной vds(8 ядер, 16Gb RAM, Ubuntu Server), сделанный на joomla с несколькими компонентами, один из которых — активно используемый форум. Всё это работало на чистом Apache+MySQL(подавляющее большинство таблиц в MyISAM). Вечером, когда на сайт приходит большое количество человек, он периодически перестаёт отвечать на запросы, т.е. по ssh зайти можно нормально, и работать в консоли, но сам сайт, если и открывается, то очень медленно. В такие моменты LA был около 14-16.

Первым делом я настроил фронтэнд(nginx), для отдачи статики и проксирования остального на апач, и поставил memcached, в котором джумла начала хранить кэш. После этого LA в пиках стал около 4. Какое то время сайт работал нормально, но через несколько дней снова начались проблемы. (LA 8-9+)

В этот раз я решил копать глубже, и, для начала, поставил munin для наблюдения за системой. Затем я установил APC, настроил размер кэша опкода так, чтобы он не переполнялся, попробовал использовать его как хранилище кэша джумлы, но испугался появившейся 100%ной фрагментации, и вернул кэш в memcached. Также я прогнал БД tuningprimer'ом, воспользовался рекомендациями, сделал больше table_cache и open_files_limit, добился того, чтобы кэша хватало. После всего этого максимальный замеченный сегодня LA был равен 5, но пользователи жаловались, что некоторое время сайт был недоступен.

В связи с этим у меня вопрос к хабрасообществу: что ещё можно сделать в этой ситуации и в какую сторону смотреть? Насколько я могу понять, проблему создаёт большое количество запросов к БД, многие даже в slow-log попадают, но что-то сделать с запросами можно только сильно залезая в код компонентов, что хочется делать только в крайнем случае. Какие графики и конфиги показать для лучшего понимания ситуации?

UPD: В планах — попробовать избавиться от apache, оставить только nginx + php-fpm. Нормально ли будет работать APC с такой связкой, и поможет ли мне вообще она?

Answer 1

[mitnlag]

1. MyISAM to InnoDB.
2. Fix your my.cnf appropriately.

MyISAM лочит при чтении всю таблицу. InnoDB только строчку. InnoDB жрет память, но обращается с ней эффективнее. InnoDB не поддерживает full text search — надо будет прикручивать сфинкс.

Comments

[Павел Вирский]

Можно ли, не меняя ничего в коде, сменить тип таблицы? Насколько я помню, у InnoDB хитрее как-то надо insert'ы и update'ы делать?
> Fix your my.cnf appropriately.
Как именно?

[Антон Корзунов]

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

[mitnlag]

Пока что вы тюнили секции конфига, подходящие для MyISAM. Основная компонента для InnoDB — Buffer_pool, который должен по возможности быть как можно больше. Все остальные параметры влияют, но это уже тонкий тюнинг и в общем совете быть дан не может.

[IlVin]

При смене MyISAM на InnoDB могут быть подводные камни в виде дедлоков (зависит от софта, работающего с БД). Так что осторожность не повредит.

[f2nd]

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

SELECT * FROM INFORMATION_SCHEMA.TABLE_STATISTICS ORDER BY ROWS_CHANGED DESC;

Answer 2

[Dzuba]

Сам по себе высокий LA не проблема и не симптом, имхо. Нужно смотреть на состав процессов и основных показателей в моменты высоких значений LA в top.

Если, например, при пиковой нагрузке высокий wa, то значит сервер «уперся» в диск и имеет смысл попытаться снизить нагрузку на дисковую подсистему при помощи простых мер: отключить access-логи, избавиться от ошибок в error-логах, указать «BufferedLogs on» в конфиге апача, поставить noatime для раздела и т.д.
При этом (и при наличии запаса по памяти), в отношении мускула не следует скупиться на: table_cache, thread_cache_size, query_cache_size, max_heap_table_size, tmp_table_size и иные «кеширующие» параметры.
Если же наоборот, при высоких LA и wa наблюдается нехватка памяти, нужно ужимать именно ее расход, поскольку система вылазит в своп, скорее всего.

Если в том же slow.log'е наиболее часто фигурируют 1-2 долгих запроса, имеет смысл разобраться с их происхождением и, в зависимости от последнего, либо избавиться от них, либо оптимизировать их.

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

Насчет связки nginx + php-fpm, одобряю, поскольку имею положительные впечатления от ее применения. Но переход на эту связку не отменяет написанного выше, ибо хуже не будет.

Comments

[Павел Вирский]

Вот, собственно, графики — www.pashinblog.ru/misc/srv/munin.html. Как раз в те три пика, пользователи и сообщали о недоступности сервера. Вроде и процессор и память не на 100% загружены, или я не так смотрю?

> Хотя в конечном итоге, при дальнейшем росте размера БД, все равно потребуется оптимизировать запросы либо менять железо.
Да, конечно, рано или поздно, к этому и придём, но нужно что-то сейчас сделать.
Спасибо.

[Павел Вирский]

Точка в конце ссылки — лишняя, разумеется. Вот так правильно — www.pashinblog.ru/misc/srv/munin.html

[Антон Корзунов]

если я не ошибаюсь у пациента воспаление дисков.
У Вас как-то очень много система проца кушает. И расскажите немного о памяти — Мунин видит все 16, и реально там в пике используются все 4

[Павел Вирский]

Да, меня тоже смутило такое использование процессора системой, но я понял почему такое происходит. Я правильно понимаю, MySQL, Apache и прочие входят в «user», а не в «system»?
Про память, если честно, не понял вопроса :)

Answer 3

[slang]

Нужно натравить профайлер на код, уменьшить время для слоулога и смотреть проблемные запросы, эксплейнить их и фиксить. Возможно кешировать результат, наверняка проблема легкорешаема на уровне кода, или решится — парой индексов/миграцией пары таблиц на ИнноДБ/заменой запроса/чисткой лишних данных/кастрацией лишнего функционала.

Comments

[Павел Вирский]

На уровне кода можно много чего сделать, проблема в том, что в него лезть ну очень не хочется. Но, похоже, никак без этого.
Запросы из слоулога проверяю, индексы стоят, вроде, нормально. Попробую самые активно используемые таблицы перевести на InnoDB. Спасибо.

Answer 4

[rtzra]

Возможно проблема в самом форуме? Если он криво написан и генерирует огромное кол-во запросов к БД — в таком случае проще переехать на другой форум, возможно даже конвертор получится найти.

Comments

[Павел Вирский]

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

Answer 5

[odmin4eg]

что на счёт кэширования?
что используете на каких уровнях?
eAcceleretor? memcached? плагины для джумлы?

Comments

[Антон Корзунов]

вы явно топик не читали :)

[odmin4eg]

Ах да, простите, как-то мимо глаз попало.
У меня есть подобная проблема но с WP и сервер «реальный».

последним шагом после многих ступеней кэширования стал переход на php5-fpm жить стало легче, посещаемость снова в гору, но не знаю сколько это продлиться до очередного хайлоада :(

Answer 6

[Пума Тайланд]

1)Определитесь кто у вас ложит сайт, медленный пхп+апач или же медленные запросы в мускул
2)Если апач+пхп сносите апц ставьте еакселератор, он существенно лучше себя показывает + к нгинксу прикручивайте php=fmp.
3)Если мускул ложит сайт, то тут уже не обойтись без оптимизации запросов, моя практика показала что существенно лучших результатов работы сайта просто подкруткой настроек мускула не добиться, один длинный запрос будет ложить сайт всегда и успешно, надо найти какие запросы ложат сайт, и потом либо отключить этот функционал если он не важен или же переписать запрос прямо.
4)Частично временно улучшить жизнь может помочь разнесение бд и апача на разные хосты.

Comments

[Антон Корзунов]

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

Answer 7

[IlVin]

По приведенным Вами графикам видно, что все упирается в процессор. Однако, не понятно что кушает процессор. Посмотрите пожалуйста тот же самый top.
Если процессор кушает MySQL, то простыми действиями не обойдешься: нужно копать в сторону форума и генерируемых им медленных запросов. Вполне вероятно, что создатели компонента/форума не имеют представления об индексах… Тогда либо тюнинг форума, либа замена форума на другой.
Я ни в коем случае не хочу бросать тень на разработчиков joomla — мне она самому нравится, но иногда могут быть ляпы…

Comments

[Павел Вирский]

Да, по моим наблюдениям за top'ом, в пиках MySQL использует около 200% процессора, больше чем всё остальное.

[IlVin]

Тогда Вам нужно разобраться какой компонент генерирует медленные запросы к БД и писать разработчикам об этой проблеме.