Настройка и оптимизация php-fpm : Linux

Некоторое время боролся с оптимизацией менеджера php, читая различные источники, пришел к выводу, что народ в большей части не понимает, как это работает и как его нужно запускать. Итак, во-первых, обращу внимание на параметр pm.status_path, который можно выставить равным в какой-то URL, например, /status.php, чтобы при запросе https://olegon.ru/status.php можно было увидеть статистику использования менеджера (у меня отключена сейчас). Да, рекомендации таковы, чтобы суффикс .php не использовать, но если его не поставить, то nginx зарулит его неизвестно куда и статистики можно не дождаться. Включаете параметр, идете по заданному url и тип-топ, обновляете по F5 статистику.
Суть использования менеджера процессов php в том, чтобы запустить минимальное количество процессов, но таким образом, чтобы при работе они не создавались постоянно новые, поскольку это занимает время и ресурсы, только при условии, что этих процессов не болталось большое количество без дела, поскольку даже пустые они потребляют ресурсы, например, память. В статистике выше будет видно их максимальное и текущее использование. Обращаю внимание, что не следует выставлять сразу в максимум, это бессмысленно, поскольку бывают какие-то обвалы, во время которых системе следует немного подтормаживать, зато цель избавления от иждивенцев будет достигнута. Например, у меня есть некоторые скрипты, при запуске которых количество процессов подскакивает до 16, но тем не менее, конфиг, как ниже.
php-fpm.conf
Конфигурация сервера - 8Гб, 4 ядра.
Поясню. Во-первых, children и servers - это одно и то же, я перерыл немало документации, пытаясь догадаться, сколько children'ов у каждого сервера и как они распределяются, подозревая аналогичность тому же апачу. Т.е. во всех случаях идет речь о процессах, выполняющих PHP-код.
Во-вторых, max_children не стоит задирать в слишком большие значения, поскольку процессы php достаточно ресурсоемки и при некотором нажиме со стороны какого-нибудь бота ваш сервер истечет памятью или завалится в своп.
В-третьих, по умолчанию backlog в конфиге 128, а в моем случае еще и был выставлен в -1, не знаю кем, возможно и мной. Это неправильно, при диком всплеске активности backlog (очередь из запросов, которые не будут успевать обрабатываться процессами) будет расти, но это подразумевает дикую загрузку и пользователь не будет дожидаться обработки своего запроса долгое время, а обрабатываться он все равно будет, даже если пользователь давно ушел. Соответственно, лучше переполнить очередь выдавать 502, чем обрабатывать кучу ненужных запросов, заставляя ждать пользователей. Естественно, если у вас обычный ресурс, а не игровой сервер, например, где надо ждать до последнего. Обращаю внимание, что при выставлении этого параметра необходимо посмотреть, как настроена система, чтобы не дать приложению задание ждать очередь, которую не поддержит системаПараметр max_requests выставлен для того, чтобы отработав 250 запросов сервер умирал, и новый сервер был создан (в случае нехватки резервных), что позволяет обновить структуру, подтекающим кривым PHP-кодом из какого-нибудь вордпресса.
Ну и к основным параметрам pm.min_spare_servers = 2 и pm.max_spare_servers = 4. Поскольку у меня 4 ядра и все время работающие 2-5 серверов (конечно не только PHP занятые), я решил, что вечное подпрыгивание с 2 до 5 процессов с их созданием - плохая идея. Для ровной работы я сконфигурировал, как видно выше, простаивающие 2 сервера в минимуме и не убивать сервера, если их 4 или менее. Речь идет о том, что если нет минимума, то сервера будут подготовлены по 2 штуки, ускоряя использование при всплеске активности (не придется создавать сервер, когда он будет нужен), а убиваться будут сервера только в случае, если их более 4 штук бездействующих.

По итогам исследования логов и странички, указанной в параметре "pm.status_path", сделал следующее
несколько раз при нагрузке не хватало детей, т.е. в итоге выдавались пустые странички, но, что еще больше пепла просыпало на мою голову, оказалось, что выравнивание количества серверов по процессорам достаточно сильно снижает производительность в целом.

Перебарщивать, конечно, не стоит, поскольку сервера едят память, но лучше pm.status_path внимательно посмотреть и выставить во всех серверах то значение, которое, так сказать, средний максимум. У меня, как правило, держится 2 активных сервера и 8 в топе, периодически подскакивает до 12-16. Так вот прикол в том, что без 8 в вышеуказанных параметрах достаточно сильно лагает. Нельзя ориентироваться на среднее количество активных. Просто периодический опрос не ловит фактическое кратковременное подскакивание, а на деле это заканчивается постоянным пересозданием процессов и тормозами.

И теперь про Zend OPcache, который встроили в PHP 5.5. Помучившись со сборкой XCache под 5.5 (почему-то крешился все время) и тем, что его как-то не очень поддерживают (год скоро с последней версии), я XCache выкинул и поставил файловый кеш в WP и VBulletin. Никаких оптимизаций и включений, кроме как в конфиге, больше не требуется, судя по phpinfo(), кеш работает без проблем. При этом и в WP и VBulletin вполне приличная скорость работы, загрузка хоста не изменилась.

В VBulletin работа выглядит значительно ровнее (за счет увеличения серверов). В WP до кучи выкинул W3 Total Cache без видимых изменений общей производительности в худшую сторону, зато со значительным ускорением работы в админке.