Какой php5-fpm, устанавливающий для высокого количества параллельных соединений + nginx

Я думаю, вы, вероятно, запускаете слишком много одновременных процессов php, но об этом трудно узнать без дополнительной информации где находятся ваши узкие места в ресурсах. Я полагаю, что вы, вероятно, ограничены дисковым вводом-выводом и / или процессором, и что все ваши параллельные процессы PHP конкурируют за них и замедляют друг друга. В какой-то момент накладные расходы на переключение процессов становятся существенным фактором, и вы получаете меньше пропускной способности, чем больше, если выполняете много процессов. Вы также можете попасть в ситуации или рискуете столкнуться с ситуациями, когда у вас заканчивается оперативная память и вы начинаете менять местами, что очень плохо. Доверяйте тому, что nginx может ставить запросы в очередь и поддерживать более высокую пропускную способность для более быстрых запросов, выполняя при этом меньше их одновременно.

I ' d обычно используют от 5 до 50 процессов PHP, причем оба конца этого диапазона немного исключительны. Чаще 10-15. С очень высокопроизводительными дисковыми системами и более чем обычными 16 или около того ядер может иметь смысл иметь больше процессов, но обычно это ложная экономия по сравнению с большим количеством более дешевых серверов. По моему опыту, если у вас нет большого количества действительно плохо написанного кода, обычно мало пользы от наличия более чем 15 процессов php параллельно на одном сервере, и если есть преимущество, скорее всего, стабильность, а не пропускная способность, в лицо патологически длительных запросов, которые накапливаются и не оставляют доступных свободных процессов.

Если у вас есть несколько баз кода с отдельными пулами процессов, вам может потребоваться большое количество процессов, но вы, вероятно, не хотите, чтобы на пул приходилось более 3-5 процессов.

Вы действительно хотите, чтобы множество рабочих соединений nginx обрабатывали статические файлы. Маловероятно, что будет какое-либо улучшение после 4096, и только в необычных обстоятельствах вы увидите разницу между 1000 и 4000. (Если вы в основном не обслуживаете статические файлы - это совсем другой сценарий, но поскольку вы говорите о процессах php на этом box Я не думаю, что здесь дело обстоит именно так)

Я подозреваю, что ваши таймауты слишком велики. Если ничего не происходит, разорвите соединение и перейдите к следующему.

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

Я подозреваю, что у вас слишком большие таймауты. Если ничего не происходит, разорвите соединение и перейдите к следующему.

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

Я подозреваю, что у вас слишком большие таймауты. Если ничего не происходит, разорвите соединение и перейдите к следующему.

1) Память. Первое, на что я обращаю внимание, это почему вашим скриптам требуется 50 МБ памяти, если все, что они делают, - это простой поиск - Я предполагаю, что вы фактически не вернули несколько мегабайт данных для каждого пользователя, если вы обслуживаете сотни запросов в секунду.

В библиотеке соединителей MySQL есть ошибка , из-за которой PHP выделить максимально возможный размер для любого ТЕКСТА или BLOB, а не просто фактический объем необходимой памяти. Это можно исправить, перейдя в библиотеку MySQLND, без необходимости изменения кода.

2) Ваша установка pm.max_requests = 10000, вероятно, не лучший выбор. Если каждый запрос занимает 2 секунды, вы говорите диспетчеру процессов перезапустить каждый процесс через 20000 секунд или почти 6 часов. Это кажется очень долгим, и было бы достаточно времени для любой утечки памяти, чтобы остановить процесс. Возврат к 500 по-прежнему будет перезапуском каждые 15 минут, что не повлияет на производительность, но, вероятно, будет более стабильно.

3) Как сказал Майкл, даже если вы можете разрешить столько процессов, сколько у вас есть подключенные пользователи, вам все равно нужно выяснить, где на самом деле находится узкое место. Даже если у вас есть несколько сотен PHP-процессов одновременно, если все они просто ждут, пока SQL-сервер станет доступным, они всегда будут просто стоять в очереди, чтобы ждать и в конечном итоге начнут отключаться.

Если вы не сможете удалить бутылку -neck вам необходимо либо реализовать механизм ограничения скорости, чтобы разрешить только столько запросов, сколько может обработать ваш сервер, либо постепенное снижение производительности для отклонения запросов, которые ваш сервер в настоящее время не может обработать.

I can't comment yet ( not enough rep ) so I will post an answer : It would be good to have your nginx logs too.

About your pool.d/www config : If you put your pm in static, most of your variables won't have any effect, it's max_children which will mainly impact your setup. ( http://php.net/manual/en/install.fpm.configuration.php ) Попробуйте, может быть, с PM "ondemand".

Не стоит начинать с pm.start_servers так высоко. Вам также следует уменьшить ваши min_spare_servers.

О конфигурации nginx: http://wiki.nginx.org/CoreModule#worker_processes "max_clients = worker_processes * worker_connections"

Ваше значение "worker_rlimit_nofile" мне кажется неверным.

Посмотрите http://wiki.nginx.org/CoreModule#worker_cpu_affinity , чтобы тоже использовать все ваши ядра .

Если все остальное не сработает ... Думаю, вы сможете справиться с этим с помощью кода. Вы можете создать «тикет-систему», чтобы разрешить определенное количество поисков одновременно, и дать вашим пользователям приблизительное время ожидания. Что-то вроде «ваш поиск начнется через N секунд».