У меня следующая конфигурация для 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.
Например, что такое pm = dynamic? есть ли другие возможные настройки для pm =? pm.max_children устанавливает ограничение на количество одновременных запросов, которые будут обслуживаться.
Значит ли это, что если у меня 51 другой посетитель, php-fpm не сможет обработать 51-го посетителя сайта?
Что происходит потом? Получает ли 51-й посетитель 404?
Я больше разработчик, чем оператор, поэтому был бы признателен за более человеческое объяснение.
Есть два типа управления процессором (PM). dynamic и static.
Статический метод очень прост. У вас есть заданное количество детей, и php-fpm всегда будет пытаться поддерживать это количество детей. Итак, если вы установите pm=static и pm.max_children = 50, у вас всегда будет 50 детей, несмотря ни на что.
Это хорошо, если у вас очень стабильный и хорошо измеряемый трафик. Это предотвращает расточительство и сокращение рабочих рук (минимальное влияние на динамику). Это также снижает непредсказуемость. Сохранить ЦП
Все остальные поля не используются, если установлены статические.
Dynamic позволяет вашим детям колебаться в счете. Это легче понять на примере.
Когда сервер загружается, он запускается в pm.start_servers. Теперь у нас 25 по вашему примеру. Предположим, 20 из них используются и поступил еще один запрос, затем он обслуживается, но количество ваших дочерних элементов увеличивается на 1, поскольку оно достигло минимального запасного порога. Помните, что процесс создания занимает много времени, поэтому вы хотите обработать его с помощью уже активного процесса. Допустим, нагрузка увеличивается еще больше, и теперь у вас 49 активных детей. Затем делается до 50, потому что это ваш максимум. Теперь предположим, что ваша нагрузка уменьшилась и осталось 14 активных. Затем он выгружает одного ребенка, чтобы получить в общей сложности 49 детей, поскольку это соответствует максимальному количеству свободных серверов. Если ваша нагрузка упадет до нуля, у вас будет 35 детей, и вы никогда не сможете опуститься ниже 35 (за исключением запросов через максимальное количество запросов, см. Ниже). Количество детей уменьшено, поэтому вы получите больше пригодного для использования барана.
Dynamic - это что-то вроде «не волнуйтесь, я оптимизирую для вас в определенных пределах».
Это хорошо, если вам нужно уменьшить объем памяти. Сохранить оперативную память
Если у вас 50 активных и вы получите еще один запрос, он, скорее всего, попадет в очередь менеджером. Хотя это сомнительно, я думаю, что он также имеет тенденцию отклонять, если длина очереди смехотворно велика. Если он остается в очереди слишком долго, запрашивающая сторона, например nginx, вернет 504 конечному пользователю по истечении времени ожидания шлюза. Чтобы избежать чего-то вроде тайм-аута всех запросов из-за бесконечной перегрузки (ddos?), Nginx обычно перестает передавать нагрузку на мертвый сервер в течение периода времени, определенного в nginx (полностью предполагая около 30 секунд), как только он достигает определенного количества ошибок. из бэкэнда.
Значение pm.max_requests определяет, сколько запросов дочерний элемент должен обработать, прежде чем уничтожить себя, чтобы новый процесс занял его место (или ничего, если он все еще находится в пределах текущего динамического статуса, как определено выше). Это помогает бороться с утечками памяти (либо в самом дочернем php-fpm, либо в вашем приложении). Итак, если произошла утечка памяти, использование памяти дочерним элементом будет продолжать расти. Почему он продолжает расти даже после завершения выполнения php, и все это то, как php-fpm оптимизирует свои процессы и прочее ... Мне кажется, это отдельное эссе.
На заметку во избежание путаницы, указанной в вашем сообщении (или отсутствия ясности). Это НИЧЕГО не имеет отношения к тому, сколько у вас посетителей или даже к тому, сколько людей просматривают ваш сайт прямо сейчас. Все дело в том, сколько php мы обрабатываем одновременно. Вы ожидаете, что большинство процессов завершится менее чем за 300 мс. По личному мнению, менее 100 мс - идеальный вариант. С более совершенным оборудованием вы можете обрабатывать быстрее, поэтому вы можете обрабатывать больше посетителей (или, точнее, запросов), несмотря на отсутствие изменений в количестве одновременных процессов.
P.S. Все, что я сказал здесь, применимо и к apache. Просто разные имена переменных.