многопоточность — как php-fpm управляет работниками с помощью динамического менеджера процессов?
Я хотел бы уточнить, как php-fpm управляет работниками с динамический менеджер процессов.
Давайте предположим, что у нас есть следующий конфиг:
pm = dynamic
pm.max_children = 100
pm.start_servers = 30
pm.min_spare_servers = 20
pm.max_spare_servers = 60
- когда запускается php-fpm, он запускает 30 процессов
- нет никаких связей Будет ли php-fpm закрывать 10 рабочих в соответствии с min_spare_servers установка? Если да, через какое время это произойдет?
- Существует 40 подключений к nginx. Будет ли php-fpm обслуживать каждое соединение с отдельным работником и сразу же создавать дополнительных работников для удовлетворения оставшихся соединений?
- Существует 80 подключений к nginx. Как поведет себя php-fpm после запуска 60 рабочих? Так же, как в (3)?
- Есть 120 подключений к nginx. Что происходит после назначения 100 рабочих на 100 соединений? Использует ли php-fpm очередь для соединений? Будет ли это ограничивать nginx? Php-fpm начнет сбрасывать соединения с сообщением «сервер достиг настройки pm.max_children«?
- Есть 50 подключений к nginx. Будет ли nginx возвращаться к 60 соединениям из 100? Или до 50? Это немедленно убьет 40 рабочих или это будет ждать некоторое время?
Как видите, это довольно обобщенный вопрос о том, как php-fpm управляет процессами. В частности, я хотел бы понять разницу между pm.max_children а также pm.max_spare_servers в php-fpm.
Решение
Прежде всего, давайте предположим, что вместо подключения nginx мы говорим о подключении / запросе к upstream, который обслуживает php-fpm.
- нет никаких связей Будет ли php-fpm выключать 10 рабочих в соответствии с настройкой min_spare_servers? Если да, через какое время это произойдет?
Нет, согласно моему тесту, основной процесс не прекращает работу дополнительных работников в соответствии с min_spare_servers число. Возможно, это хорошая практика, чтобы уточнить start_servers равно min_spare_servers,
- Существует 40 подключений к nginx. Будет ли php-fpm обслуживать каждое соединение с отдельным работником и сразу же создавать дополнительных работников для удовлетворения оставшихся соединений?
Правильные одновременные подключения к php-fpm будут обслуживаться отдельным работником. Если количество запросов превышает start_servers мастер процесс раскошелитсяfpm_children_make звоните), до max_spare_servers,
- Существует 80 подключений к nginx. Как поведет себя php-fpm после запуска 60 рабочих? Так же, как в (3)?
Он обработает столько рабочих, сколько необходимо для обработки всех запросов одновременно, пока не достигнет max_children число; ведущий процесс fpm выполняет обслуживание каждую секунду (fpm_pctl_perform_idle_server_maintenance колл): если количество появившихся рабочих больше max_spare_servers, рабочие в нерабочем состоянии отправят SIGCHLD сигнал для мастер-процесса (fpm_got_signal а также fpm_children_bury звонки).
- Есть 120 подключений к nginx. Что происходит после назначения 100 рабочих на 100 соединений? Использует ли php-fpm очередь для соединений? Будет ли это ограничивать nginx? Будет ли php-fpm начинать сбрасывать соединения с сообщением «сервер достиг настройки pm.max_children»?
Правильно, вы будете следить за сообщением в режиме отладки:
seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers
- Есть 50 подключений к nginx. Будет ли nginx возвращаться к 60 соединениям из 100? Или до 50? Это немедленно убьет 40 рабочих или это будет ждать некоторое время?
Все работники, находящиеся в нерабочем состоянии, будут прерваны, а основной процесс остановится после номера max_spare_servers достигнуто
параметры min_spare_servers а также max_spare_servers несут ответственность за минимальное и максимальное количество работников, которые могут одновременно находиться в состоянии ожидания.
Чтобы понять dipper, попробуйте включить вход в систему отладки. php-fpm.conf:
...
error_log = /var/log/php5-fpm/fpm-daemon.log
...
log_level = debug
...
Следуйте лог-файл: tail -f /var/log/php5-fpm/fpm-daemon.log и использовать Apache Benchmark Tool ab понимать поведение.
Другие решения
Других решений пока нет …