Заказывая оптимизацию сервера у хостера — держи ухо востро

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

Это была бы рядовая и унылая статья про nginx и opcode-кеширование, если бы сервер не был до этого "прооптимизирован" техподдержкой хостера :-)

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

Поскольку требовалось быстрое решение (на 1 час работы), я пошел по стандартному пути: nginx/Ускоритель PHP/expires у статики/отключение access-логов. nginx уже был, а остальное было сделано к 3-му числу. Краем глаза отметил, что PHP работает в режиме CGI, а не mod_php (трогать это сразу не стал - тут всегда надо разбираться, не было ли где-то что-то завязано на юзера из-под которого работал PHP). Улучшение производительности конечно было (см. график справа), но очень далеко от того, на что я рассчитывал (на графике доступно только 50% CPU, так что там где график касается 50% - все становится очень плохо). Кроме того, когда проснулся утром, увидел письмо о том что часть страниц перестала работать (и как назло, страницы которые я смотрел после изменения настроек - работали).

Пошел смотреть подробнее второй раз, начиная с CGI. Я такого вообще никогда не видел, mod_php везде давно и по умолчанию, и по всем параметрам быстрее CGI (про FCGI я тут не говорю). А как мы знаем, при работе в режиме CGI opcode-кеш APC не шарится между процессами PHP, и соответственно никакого прироста производительности от него не выходит.

Неработающие страницы оказались из-за конфликта APC и Zend Optimizer(не ожидал однако его тут увидеть) - оно вообще не должно было работать, но часть страниц чудом работали.

Побеседовав с заказчиком выясняю, что так сервер настроила техподдержка на запрос об оптимизации. Давайте внимательнее глянем, что они им настроили:

Что было настроено хостером по сравнению с конфигурацией по умолчанию:

1) nginx: 8 процессов, по 65к соединений (при том что сервер умирает уже от 100, а nginx готовится обработать 650'000). expires статики не настроен (не говоря уже об отдаче статики напрямую без Apache2). Access логи пишутся и в Apache, и в nginx.
2) PHP в режиме CGI. Это исключает использование популярных ускорителей PHP. Zend Optimizer практически не помогает. Самый медленный режим работы PHP, хуже трудно что-то придумать.
3) Apache за nginx рьяно пытается запустить до 150 процессов себя и до 150 процессов PHP. Очевидно, что память выжирается очень бодро. Хостер рекомендует перейти на более толстый тариф, и заказчик собственно переходит, впрочем и более толстого тарифа надолго не хватает.
4) MySQL с конфигом под 50Мб используемой памяти (при доступном гигабайте).

Что было настроено мной/нужно было настроить с самого начала:

1) nginx, 1 процесс (рядовому серверу и 10000 соединений "в стоячем" состоянии не видать, остальное - лишний расход памяти). Отдача заголовков expires для статики.
2) PHP в режиме по-умолчанию, mod_php. Любой PHP opcode cache (например APC).
3) apache2 ограничен 8-16 процессами = фиксированный расход памяти.
4) MySQL - конфиг на половину доступной памяти.

Результат виден 4-го числа. Нагрузка резко снижается, расход памяти теперь стабильный, и позволяет перейти на тариф вдвое дешевле (впрочем, делать этого не стали, т.к. посещаемость быстро растет).

Резюме

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

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

Так что следите за тем, что Вам там настраивает хостер и не спускайте глаз с графиков munin-а