Пару дней назад обратился ко мне человек с достаточно рутинной просьбой: подкрутить настройки 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-а