Конфигурация php5-fpm pm - (node) Узлы настроек диспетчера процессов в более широком смысле
У меня есть следующая конфигурация для php-fpm
[www]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
user = www-data
group = www-data
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 2500
pm.status_path = /php-status
Я прочитал эту страницу документации.
Был бы признателен за более человеческое объяснение настроек, связанных с вечера.
Например, что такое pm = dynamic? Есть ли другие возможные настройки для вечера =? pm.max_children устанавливает ограничение на количество одновременных запросов, которые будут обслуживаться.
Значит ли это, что если у меня 51 посетитель, php-fpm не сможет обработать 51-го посетителя сайта?
Что происходит потом? Получает ли 51-й посетитель 404?
Я больше dev, чем ops, поэтому был бы признателен за более человеческое объяснение.
1 ответ
Существует два типа управления процессором (PM). dynamic а также static,
статический
Статический метод очень прост. У вас есть определенное количество детей, и php-fpm всегда будет пытаться сохранить это количество детей. Итак, если вы установите pm=static а также pm.max_children = 50у тебя всегда будет 50 детей, несмотря ни на что.
Это хорошо, если у вас очень стабильный и хорошо измеренный трафик. Это предотвращает расточительство и сокращение работников (минимальное влияние на динамику). Это также снижает непредсказуемость. Сохранить процессор
Все остальные поля не используются, если установлено статическое.
динамический
Динамический позволяет вашим детям колебаться. Проще разобраться с примером по ходу дела.
Когда сервер загружается, он начинается с pm.start_servers, У нас сейчас 25 по вашему примеру. Допустим, 20 из них используются, и поступил другой запрос, который затем обрабатывается, но количество ваших детей увеличивается на 1, поскольку оно достигло минимального запасного порога. Помните, что создание процесса занимает много времени, поэтому вы хотите обработать его с помощью уже активного процесса. Допустим, нагрузка увеличивается больше, и теперь у вас 49 активных детей. Тогда до 50 сделаны, потому что это ваш максимум. Теперь предположим, что ваша нагрузка уменьшается, и есть 14 активных. Затем он разгрузит одного ребенка, чтобы охватить всего 49 детей, поскольку он соответствует вашим максимальным запасным серверам. Если ваша нагрузка снизится до нуля, у вас будет 35 детей, и вы никогда не сможете опускаться ниже 35 (за исключением максимального числа запросов, см. Ниже). Количество детей уменьшено, так что вы получите более полезный баран обратно.
Dynamic - это что-то вроде "не волнуйтесь, я буду оптимизировать для вас в определенных пределах".
Это хорошо, если вам нужно держать память на низком уровне. Сохранить RAM
Запросы сверх макс
Если у вас есть 50 активных и вы получили еще один запрос, он, скорее всего, попадет в очередь менеджера. Несмотря на неопределенность, я думаю, что он также имеет тенденцию отклоняться, если длина очереди смехотворно велика. Если он остается в очереди слишком долго, запрашивающая сторона, такая как nginx, вернет 504 конечному пользователю по истечении времени ожидания шлюза. Чтобы избежать истечения времени ожидания всех запросов из-за бесконечной перегрузки (ddos?), Nginx обычно перестает передавать нагрузку на неработающий сервер на период времени, определенный в nginx (примерно 30 секунд), как только он достиг определенного числа ошибок из бэкэнда.
Макс запросов
Значение pm.max_requests определяет, сколько запросов должен обработать дочерний элемент, прежде чем уничтожить себя, чтобы новый процесс занял свое место (или ничего, если он все еще находится в пределах текущего динамического состояния, как определено выше). Это помогает бороться с утечками памяти (как в самом php-fpm, так и в вашем приложении). Таким образом, если произошла утечка памяти, использование памяти ребенком будет продолжать расти. Почему он продолжает расти даже после завершения выполнения php, и все это - то, как php-fpm оптимизирует свои процессы и прочее... Я чувствую, что это отдельное эссе.
Отметить для предотвращения путаницы, обозначенной вашим постом (или отсутствием ясности). Это НИЧЕГО не связано с тем, сколько у вас посетителей или даже сколько людей просматривают ваш сайт прямо сейчас. Все дело в том, сколько php мы обрабатываем одновременно. Вы ожидаете, что большинство процессов завершится менее чем за 300 мс. До 100 мс как идеал по личному мнению. Благодаря более качественному оборудованию вы сможете обрабатывать быстрее и обрабатывать больше посетителей (или, точнее, запросов), несмотря на отсутствие изменений в количестве одновременных процессов.
PS Все, что я здесь сказал, относится и к apache. Просто разные имена переменных.