Ежовый угол

В течение последних нескольких дней доступ к блогу был затруднен в связи с превышением нагрузки блогом на сервер в 10-15 раз. Администратор Spaceweb деликатно сообщил о превышении нагрузки и попросил принять меры, т.к. пообещал в противном случае перенести аккаунт на карантинный сервер, а затем и вовсе отключить. Я сему известию был очень удивлен — ежедневная посещаемость не превышает 3-4 тыс уникальных посетителей.

Ежедневные отчеты о нагрузке выглядели неутешительно: 

+————————————————————————+
| server | user | cp_stat | quota | date | warnings | errors |
+————————————————————————+
| dharma | rudomilov | 486.75 | 100 | 2008-11-03 | 31297 | 3718 |
| dharma | rudomilov | 424.78 | 100 | 2008-11-04 | 21225 | 2027 |
| dharma | rudomilov | 172.31 | 99 | 2008-11-05 | 7939 | 511 |
| dharma | rudomilov | 559.8 | 99 | 2008-11-06 | 37200 | 3098 |
| dharma | rudomilov | 165.46 | 100 | 2008-11-07 | 12173 | 106 |
| dharma | rudomilov | 495.91 | 100 | 2008-11-08 | 27594 | 2418 |
| dharma | rudomilov | 508.29 | 100 | 2008-11-09 | 32409 | 3512 |
| dharma | rudomilov | 632.68 | 100 | 2008-11-10 | 38976 | 2790 |
| dharma | rudomilov | 272.22 | 100 | 2008-11-11 | 20310 | 1307 |
| dharma | rudomilov | 489.84 | 100 | 2008-11-12 | 33690 | 1901 |
+————————————————————————+

В таблице приведены следующие значения: cp_stat — статистическая процессорная
нагрузка аккаунта на сервер, warnings — число превышений нагрузки на процессор
более 10% (втечение 5 секунд), errors — число превышений нагрузки на процессор
более 50% (втечение 5 секунд). В первую очередь стоит обратить внимание на
параметр cp_stat (безразмерная величина, характеризующая статистическую нагрузку
на процессор втечение суток) — она не должна превышать заданных норм. Такими нормами
для виртуального хостинга (кроме тарифа VIP) является значение 50 и для тарифа VIP
значение — 90. Также необходимо обратить внимание на столбцы warnings и errors.
Число errors должно быть равно 0, а warnings должно стремиться к нулю. Нормально
отлаженные работающие скрипты среднего сайта не должны отнимать более 3% процессорного
времени более 3-5 секунд. Если это не так, и дальнейшая оптимизации невозможна,
следовательно необходимо рассмотреть вариант размещения проекта на выделенном сервере.

В попытках локализовать проблему было проведено немало часов и написано с десяток писем в spaceweb (он же sweb)  по поводу потенциальных источников проблемы. По утрам все было более-менее нормально, а к вечеру сайт вообще не грузился (хотя согласно показаниям счетчиков Liveinternet и Rambler’s TOP100, многие посетители все же могли зайти на блог).

Мониторинг

Для определения наиболее «тяжелых» элементов шаблонов удобно использовать WP Tuner, о котором писал Lecactus. После его установки и включения на всех страницах блога администраторы смогут видеть блок статистики выполнения скриптов:

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

Кеширование

Перво-наперво установил WP Super Cache (подробное описание), который выгодно отличается о WP Cache, на основе которого построен. WP Super Cache обладает возможностями создания абсолютно чистого HTML, без единого вызова PHP-кода. Кроме того, созданный кеш он может размещать непосредственно по вызываемому адресу (секция настроек «Directly Cached Files») — т.е., к примеру, в /2008/10/05/article/ Установка незатейлива — отключаем WP Cache (если он был установлен) и распаковываем в /wp-content/plugins/ архив с WP Super Cache. Затем активируем его в разделе «Плагины» панели управления администратора и идем в «Настройки»->»WP Super Cache», где ставим в разделе «WP Super Cache Status» переключатель на «ON». Время обновления кеша указывается в «Expiry Time and Garbage Collection» — в текстовом поле указывается время жизни кеша, а переключателем устанавливается периодичность удаления устаревшего кеша. Для ручной очистки кеша используются кнопки «Delete cache» (удалить весь кеш) и «Delete expired» (удалить устаревший кеш) в секции «Cache Contents».

Виновник — OWA

Как выяснилось в конце-концов, проблема была в статистике OWA (Open Web Analytics), о которой я писал ранее. С отключением OWA нагрузка спала и проблема вроде не проявляется. Правда, пришлось также вручную удалить папку /wp-content/plugins/owa/owa-data/caches/1/, т.к. она разрослась за 8 месяцев на 4,5 Гб. В последние дни нагрузка упала до более-менее приемлемых значений:

| dharma | rudomilov | 86.74 | 100 | 2008-11-13 | 3194 | 494 |
| dharma | rudomilov | 64.38 | 26 | 2008-11-14 | 3048 | 363 |