Перейти к содержимому 
Очередь запросов в PHP ограничивает количество запросов, обрабатываемых вашим сервером одновременно, и, следовательно, определяет время отклика, количество ошибок и удобство работы пользователей. Я покажу вам, как Пределы обработки устранить "узкие места" и добиться последовательной доставки благодаря согласованным параметрам.
Центральные пункты
Чтобы вы могли сразу же приступить к работе, я расскажу о наиболее важных регулировочных винтах для PHP-FPM вместе.
- pm.max_children: Рассчитайте верхний предел для одновременных процессов PHP, чтобы соответствовать объему оперативной памяти.
- список.задержка: Максимально возможная кратковременная буферизация попыток подключения во время пиковых нагрузок.
- pm.max_requestsРегулярно перерабатывайте процессы, чтобы избежать утечек и разрастания памяти.
- Тайм-ауты: последовательно устанавливайте таймауты request_terminate_timeout, max_execution_time и таймауты веб-сервера.
- МетрикиДостигнуто максимальное количество детей, постоянно проверяйте очередь прослушивания и медленные журналы.
Я фокусируюсь на четких ключевых показателях и измеримых эффектах, чтобы каждая корректировка Лимиты остается прослеживаемым. Для каждого изменения я отслеживаю журналы и время отклика, прежде чем планировать следующий шаг и постепенно увеличивать или уменьшать значения. Таким образом я предотвращаю побочные эффекты, такие как подмена памяти, которая может Очередь значительно дольше. Благодаря такому подходу я контролирую пики нагрузки и поддерживаю стабильное время отклика. Цель - добиться сбалансированной загрузки мощностей, которая Ресурсы эффективно, не перегружая хост.
Как работает очередь запросов PHP в PHP-FPM
Каждый входящий HTTP-запрос требует своего собственного Рабочий, и рабочий обслуживает только один запрос за раз. Если все процессы заняты, дальнейшие вызовы попадают в Очередь и ждать, пока процесс не освободится. Если эта очередь растет, время отклика увеличивается, а ошибки типа 502/504 возникают чаще. Поэтому я обращаю внимание на разумное соотношение между количеством процессов и доступной памятью, а не слепо фокусируюсь на максимальном параллелизме. Таким образом, я добиваюсь постоянной пропускной способности без RAM или процессор отделится.
Чистый выбор режимов диспетчера процессов
В дополнение к предельным значениям режим pm отзывчивость и потребление ресурсов:
- пм = динамикаЯ определяю start_servers, min_spare_servers и max_spare_servers. Этот режим является моим стандартом для переменных нагрузок, потому что он быстро реагирует на увеличение и поддерживает теплые процессы в готовности.
- pm = ondemandПроцессы создаются только при необходимости и завершаются по истечении process_idle_timeout. Это экономит оперативную память при нечастых обращениях (админка, стейджинг, конечные точки cron), но может привести к потере оперативной памяти в случае внезапных пиков. холодные запуски и более высокая задержка. Поэтому я использую его выборочно и с большим запасом.
- pm = static: Фиксированное количество процессов. Идеально, если у меня есть жесткий верхний предел и особенно предсказуемые задержки (например, прокси L7 перед несколькими, но критичными конечными точками). Потребность в оперативной памяти поддается четкому расчету, но неиспользуемые процессы занимают память.
Я решаю, какой режим подходит для каждого пула. Обычно я использую динамический режим для фронтендов с меняющейся нагрузкой, режим по требованию для служебных пулов и статический режим для выделенных, критичных к задержкам сервисов.
Правильное определение pm.max_children
Самым важным рычагом является pm.max_children, потому что это значение определяет, сколько запросов может выполняться одновременно. Я рассчитываю начальный размер, используя эмпирическое правило: (свободно доступная оперативная память - 2 ГБ резерва), деленное на среднее количество памяти на один процесс PHP. В качестве грубого допущения я использую 40-80 МБ на процесс и изначально начинаю с 200-300 процессов на хосте с 32 ГБ. Под нагрузкой я постепенно увеличиваю или уменьшаю количество процессов и проверяю, увеличивается ли время ожидания Очередь падает, и коэффициент ошибок уменьшается. Если вы хотите углубиться, то можете найти справочную информацию о начальных и предельных значениях на сайте Оптимизация pm.max_children.
Координирование начальных, запасных и резервных значений
Я установил pm.start_servers примерно 15-30 процентов от pm.max_children, чтобы при запуске было доступно достаточно процессов и не было холодных стартов. С помощью pm.min_spare_servers и pm.max_spare_servers я определяю разумное окно для свободных процессов, чтобы новые запросы не ждали и в то же время не занимали память ненужными простоями. Listen.backlog имеет особое значение: Этот буфер ядра ненадолго задерживает дополнительные попытки подключения, когда все рабочие заняты. Для пиков нагрузки я устанавливаю большие значения (например, 65535), чтобы очередь не останавливается перед пулом FPM. Более подробную справочную информацию о взаимодействии между веб-сервером, восходящим потоком и буферами можно найти в обзоре Очередь на веб-сервер.
Ограничение времени выполнения запросов и переработка процессов
Я предотвращаю ползучие скачки памяти с помощью pm.max_requests, который перезапускает каждый процесс после X запросов. Ненавязчивые приложения часто хорошо работают при 500-800, если есть подозрения на утечку памяти, я снижаю до 100-200 и наблюдаю за эффектом. Кроме того, request_terminate_timeout инкапсулирует выбросы, завершая очень длинные запросы через фиксированное время. Последовательность очень важна: я держу max_execution_time PHP и таймауты веб-сервера в одном коридоре, чтобы один уровень не завершался раньше другого. Такое взаимодействие позволяет поддерживать Рабочий свободен и защищает бассейн от перегруженности.
Сделайте очереди видимыми: Журналы и метрики
Я регулярно читаю журналы FPM и обращаю внимание на максимальное количество детей, потому что эта запись указывает на то, что верхний предел процессов достигнут. В то же время я слежу за очередью прослушивания, которая выявляет растущее отставание во входном буфере. В сочетании с request_slowlog_timeout я получаю трассировку стека для выявления медленных точек в коде и изолирую тормоза базы данных или API. Я сопоставляю upstream_response_time из журналов веб-сервера с request_time и кодами состояния, чтобы определить источник длительного времени отклика. Это позволяет мне определить, является ли узким местом PHP-FPM или База данных или вышестоящей сети.
Профили рабочей нагрузки: Ограничение процессора против ограничения ввода-вывода
Для процессов, требующих большого количества процессора, я масштабирую Параллелизм Я осторожен и ориентируюсь на количество vCPU, поскольку дополнительные процессы почти не приносят пропускной способности. Если речь идет в основном о нагрузке IO с доступом к базе данных или внешним API, я могу разрешить больше процессов, если бюджет оперативной памяти достаточен. Для оформления заказа в электронной коммерции полезны более длительные тайм-ауты (например, 300 с), чтобы завершить способы оплаты без отмены. Я перехватываю флэш-продажи, устанавливая высокий уровень listen.backlog и увеличивая свободное окно. Информация о балансе между количеством процессов и производительностью хоста содержится в руководстве по PHP-Workers как узкое место.
Образцы расчетов и определения размеров
Сначала я вычисляю объем памяти на процесс, а затем получаю разумный Верхний предел выключен. Затем я провожу тестирование под реальной нагрузкой и наблюдаю, уменьшается ли очередь и увеличивается ли пропускная способность. Консервативные начальные значения снижают риск подмены и сохраняют равномерное время отклика. Затем я уточняю значения небольшими шагами, чтобы быть уверенным в том, что не замечу никаких побочных эффектов. В следующей таблице приведены рекомендации по начальным значениям и их влиянию на Очередь.
| Параметры | Эффект | Начальное значение (пример) | Подсказка |
|---|---|---|---|
| pm.max_children | Макс. одновременный Процессы | 200-300 (с 32 ГБ) | Сравните с бюджетом оперативной памяти и размером процесса |
| pm.start_servers | Первоначальное количество работников | 15-30 % от max_children | Избегайте холодного пуска, а холостой ход сводите к минимуму |
| pm.min_spare_servers | Бесплатно Рабочий Минимум | z. B. 20 | Прямое включение новых запросов |
| pm.max_spare_servers | Максимум свободного работника | z. B. 40 | Ограничьте потребление оперативной памяти неработающими процессами |
| список.задержка | Буфер ядра для попыток подключения | 65535 | Амортизация пиковых нагрузок и сокращение перерывов в подключении |
| pm.max_requests | переработка отходов Интервал | 500-800, с утечками 100-200 | Минимизация раздувания памяти и зависаний |
| request_terminate_timeout | Жесткий лимит запросов | 300-600 s | Соответствует таймаутам PHP и веб-сервера |
Практические шаблоны для пулов PHP FPM
Для магазина с большим количеством обращений к чтению я устанавливаю умеренное значение Показатели процесса и увеличьте свободное окно, чтобы запросы не стояли в очереди. Для контентных страниц с кэшированием часто достаточно значительно меньшего количества рабочих, если NGINX или Apache эффективно доставляют статический контент. Я разделяю многопулы по частям приложения, которые имеют разные профили памяти, чтобы ни один тяжелый пул не вытеснял другие. Я определяю отдельные пулы с собственными правилами таймаута для рабочих cron или очередей. Вот как я поддерживаю интерактивность Трафик бесплатно и не замедляет никаких действий пользователя.
Тайм-ауты веб-сервера, восходящий поток и сокеты
Я рассматриваю таймауты FastCGI и прокси из Nginx или Apache в том же окне, что и таймауты FPM, чтобы ни один уровень не завершился слишком рано. Я предпочитаю Unix-сокеты TCP, если обе службы работают на одном хосте, потому что задержка остается минимальной. Для распределенных систем я использую TCP со стабильными значениями keepalive и достаточно большим пулом соединений. При высоком параллелизме nginx синхронизирует значения worker_connections и FPM backlog. Это обеспечивает быструю переадресацию и позволяет избежать простоя из-за слишком плотного соединения. вверх по течению-лимиты.
Кэширование, OPCache и база данных как рычаги
Я решаю многие проблемы сервера, сокращая количество дорогостоящих операций и минимизируя Время отклика ниже. Я включаю OPCache, разумно увеличиваю лимит памяти кэша и обеспечиваю высокий коэффициент попадания в кэш. Для получения повторяющихся результатов я использую кэширование приложений, чтобы процессы PHP завершались быстрее. На стороне базы данных я оптимизирую медленные запросы и активирую кэши запросов, подходящие для используемой системы. Каждая сэкономленная миллисекунда снижает нагрузку на Очередь и увеличивает пропускную способность на одного работника.
Безопасные аварийные механизмы и перезапуск
Я активирую порог_аварийного_перезапуска и emergency_restart_interval, чтобы мастер FPM перезапускался, если слишком много дочерних систем падают в быстрой последовательности. Такой контролируемый перезапуск предотвращает цепную реакцию и сохраняет доступность службы. В то же время я устанавливаю четкие ограничения на память и количество процессов, чтобы предотвратить эскалацию. Проверка работоспособности на стороне восходящего потока автоматически удаляет неисправные бэкенды из пула и снижает количество ошибок. Это позволяет сохранить Наличие пока я выясняю истинную причину.
Тонкая настройка ограничений операционной системы и systemd
Так что список.задержка на самом деле вступает в силу, я настраиваю ограничения ядра. Значение ОС net.core.somaxconn должно быть не меньше установленного отставания, иначе система отключает очередь. Я также проверяю количество разрешенных файловых дескрипторов: В пуле FPM я могу установить rlimit_files, на уровне служб я обеспечиваю LimitNOFILE (systemd), а на уровне ядра - fs.file-max. Веб-серверу нужны аналогичные резервы, чтобы он не достиг своих пределов раньше времени.
Для более стабильных задержек я уменьшаю vm.swappiness, чтобы ядро не вытесняло активно используемые страницы памяти раньше времени. В установках, критичных к задержкам, я отключаю Прозрачные огромные страницы, чтобы избежать длинных ошибок страниц. Если FPM работает через TCP, я также синхронизирую параметры net.ipv4.tcp_max_syn_backlog и reuse/keepalive. Такие детали ОС кажутся незаметными, но они решают, будут ли очереди гладкий истекает, или если соединения уже отклонены до FPM.
Измерьте нагрузку на память каждого процесса
Вместо того чтобы делать обобщенные оценки, я измеряю Реальное потребление на одного рабочего при реальной нагрузке. Я использую такие инструменты, как ps, smem или pmap, фильтрую дочерние php-fpm и усредняю значения RSS во время выполнения запросов. Важно учитывать использование общего OPCache: общая память не учитывается несколько раз. Я вычисляю pm.max_children из усредненного значения, а также планирую резерв, чтобы машина не оказалась в узком месте даже во время пиков. своп наклоны.
Я повторяю это измерение после изменения функций или релизов. Новые функции, увеличение количества зависимостей или изменения во фреймворках могут значительно увеличить площадь, занимаемую одним процессом. Таким образом, количество процессов остается реалистичным, а очередь - короткой.
Состояние PHP FPM, пинг и метрики в реальном времени
Чтобы быстро оценить ситуацию, я активирую pm.status_path и Пинг конечной точки (ping.path/ping.response). Поверх этого я могу видеть такие ключевые показатели, как принятое соединение, длина очереди прослушивания, простаивающие/занятые процессы, максимальное количество достигнутых дочерних соединений и их прогрессию. Я периодически считываю эти значения и устанавливаю пороговые значения: если очередь прослушивания постоянно увеличивается, я либо увеличиваю количество процессов, либо устраняю причину медленных запросов. Если max children reached скачет вверх, а idle остается низким, то пул слишком мал или заблокирован длинные бегуны.
Я также разделяю пулы с разными профилями, чтобы скачки в одной области (например, импорт API) не приводили к падению интерактивного трафика. В диагностических случаях я временно повышаю уровень log_level и позволяю медленному журналу захватить больше образцов, но затем снова снижаю его, чтобы сохранить низкую нагрузку на ввод-вывод.
Загрузка, буферизация и большие тела запросов
Большие загрузки могут излишне затянуть работу, если PHP придется сначала прочитать тело запроса. Я убеждаюсь, что веб-сервер буферы (например, fastcgi_request_buffering для NGINX), чтобы FPM запускался только тогда, когда тело завершено. Это означает, что ни один рабочий не блокируется во время загрузки. Я использую client_max_body_size, post_max_size и max_input_time, чтобы контролировать, насколько большими и длинными могут быть запросы, не подвергая опасности конечные точки. Если между ними находятся файлы, я выделяю достаточно быструю временную память (SSD), чтобы избежать заторов в буфере.
Для конечных точек с очень большими телами (например, экспорт/импорт) я определяю выделенные пулы с собственными таймаутами и меньшим параллелизмом. Таким образом, стандартные рабочие остаются свободными, а Очередь важных действий пользователя.
Подключения к базам данных и границы пулов
Даже самая лучшая настройка FPM бесполезна, если База данных ранее было ограничено. Я согласовываю максимальное количество одновременных процессов PHP с реальной доступной емкостью БД. Для постоянных соединений или пулов соединений я убеждаюсь, что сумма всех пулов равна на сайте max_connections остается. Если есть много коротких запросов, стоит умеренно ограничить параллелизм PHP, чтобы БД не металась между тысячами сессий.
Медленные транзакции быстро вызывают отставание в очереди FPM. Поэтому я анализирую время ожидания блокировки, использование индексов и планы запросов. Каждое сокращение времени работы БД немедленно уменьшает PHPПродолжительность документа и уменьшает длину очереди.
Выпуск и развертывание без скачков
При выпуске новых версий я избегаю холодных кэшей и бури процессов. Я использую перезагрузить вместо жестких перезапусков, чтобы существующие рабочие запросы завершались чисто (обратите внимание на process_control_timeout). Я разогреваю OPCache на ранней стадии, запуская критические пути один раз перед переключением или работая с предварительной загрузкой. Это предотвращает одновременный разбор файлов классов многими рабочими и Время отклика увеличивается в разы.
При использовании синей/зеленой или канареечной стратегий я постепенно увеличиваю нагрузку и слежу за состоянием страниц. Только когда очередь, количество ошибок и задержки остаются стабильными, я увеличиваю долю трафика. Такой контролируемый подход защищает от пиков нагрузки во время развертывания.
Специализация по контейнерам и виртуальным машинам
В контейнерах, воспринимаемых Общий объем хранилища часто ниже, чем сообщает хост. Я выравниваю pm.max_children строго по лимиту cgroup и планирую резерв против убийцы OOM. Ограничения памяти в PHP (memory_limit) и площадь на процесс должны совпадать, иначе одного превышения достаточно для завершения работы контейнера.
Если в контейнере нет свопа, жесткие отмены более вероятны. Вот почему я сохраняю консервативность процессов, активирую рециркуляцию и отслеживаю пики нагрузки на производство по RSS. Несколько пулов часто оказываются более надежными, чем один большой монолитный пул.
Контролируемая деградация и противодавление
Если Очередь Я полагаюсь на контролируемую деградацию: я намеренно предоставляю 503 повторных попытки для некритичных конечных точек в случае перегрузки, сокращаю дорогостоящие функции (например, живой поиск) и ограничиваю параллельный доступ к горячим точкам. Благодаря этому система остается отзывчивой, пока я устраняю причину, а не все пользователи сталкиваются с тайм-аутом.
Краткое резюме
Я приношу Очередь запросов в PHP под контролем благодаря умному подбору количества параллельных процессов в соответствии с бюджетом оперативной памяти и типом нагрузки. Высокие значения бэклога буферизируют пики, тайм-ауты на всех уровнях четко соответствуют друг другу, а рециркуляция устраняет прокрадывающиеся проблемы с памятью. Журналы и метрики показывают мне, растет ли очередь, где запросы застревают и когда нужно подтянуться. Благодаря тщательной настройке и целенаправленному кэшированию я сокращаю время обработки одного запроса и увеличиваю пропускную способность. Таким образом, серверы работают стабильно и не требуют больших затрат. Тайм-ауты в повседневной жизни.
