Добрый вечер, хабр. Прошу у вас помощи в анализе графиков загрузки сервера, и его оптимизации, думаю я что-то упускаю из вида, или просто не понимаю.
Предыстория: достался в наследство один сайт, расположенный на достаточно мощной 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 с такой связкой, и поможет ли мне вообще она?
1. MyISAM to InnoDB.
2. Fix your my.cnf appropriately.
MyISAM лочит при чтении всю таблицу. InnoDB только строчку. InnoDB жрет память, но обращается с ней эффективнее. InnoDB не поддерживает full text search — надо будет прикручивать сфинкс.
Сам по себе высокий 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, одобряю, поскольку имею положительные впечатления от ее применения. Но переход на эту связку не отменяет написанного выше, ибо хуже не будет.
Нужно натравить профайлер на код, уменьшить время для слоулога и смотреть проблемные запросы, эксплейнить их и фиксить. Возможно кешировать результат, наверняка проблема легкорешаема на уровне кода, или решится — парой индексов/миграцией пары таблиц на ИнноДБ/заменой запроса/чисткой лишних данных/кастрацией лишнего функционала.
Возможно проблема в самом форуме? Если он криво написан и генерирует огромное кол-во запросов к БД — в таком случае проще переехать на другой форум, возможно даже конвертор получится найти.
1)Определитесь кто у вас ложит сайт, медленный пхп+апач или же медленные запросы в мускул
2)Если апач+пхп сносите апц ставьте еакселератор, он существенно лучше себя показывает + к нгинксу прикручивайте php=fmp.
3)Если мускул ложит сайт, то тут уже не обойтись без оптимизации запросов, моя практика показала что существенно лучших результатов работы сайта просто подкруткой настроек мускула не добиться, один длинный запрос будет ложить сайт всегда и успешно, надо найти какие запросы ложат сайт, и потом либо отключить этот функционал если он не важен или же переписать запрос прямо.
4)Частично временно улучшить жизнь может помочь разнесение бд и апача на разные хосты.
По приведенным Вами графикам видно, что все упирается в процессор. Однако, не понятно что кушает процессор. Посмотрите пожалуйста тот же самый top.
Если процессор кушает MySQL, то простыми действиями не обойдешься: нужно копать в сторону форума и генерируемых им медленных запросов. Вполне вероятно, что создатели компонента/форума не имеют представления об индексах… Тогда либо тюнинг форума, либа замена форума на другой.
Я ни в коем случае не хочу бросать тень на разработчиков joomla — мне она самому нравится, но иногда могут быть ляпы…
My<cod/>.net
