Планирование ресурсов PHP-FPM: расчет количества рабочих процессов, объёма оперативной памяти и количества одновременных запросов

Что ограничивает рабочий процесс PHP-FPM

PHP-FPM управляет процессами PHP в пулах. Один Рабочий обрабатывает по одному запросу; настройка пула pm.max_children ограничивает количество одновременно доступных рабочих процессов и, следовательно, количество PHP-запросов, одновременно обрабатываемых этим пулом. При наличии нескольких пулов это ограничение действует только для конкретного пула, а не автоматически для всего сервера.

Эта цифра не является ни количеством авторизованных посетителей, ни прямым показателем количества запросов в секунду. Один посетитель может инициировать несколько запросов, в то время как авторизованный пользователь не занимает рабочий процесс между двумя действиями. И наоборот, один медленный запрос может занять рабочий процесс дольше, чем несколько коротких запросов подряд.

Кроме того, не каждый запрос на страницу доходит до PHP-FPM. Если веб-сервер напрямую предоставляет статический файл или предшествующий кеш полностью удовлетворяет запрос, то, в зависимости от архитектуры, PHP-рабочий процесс не требуется. В то же время промахи кеша, авторизованные пользователи и административные страницы могут по-прежнему генерировать запросы PHP и кратковременно увеличивать загрузку.

Поэтому для планирования мощностей решающее значение имеют два отдельных вопроса: сколько рабочих процессов с запасом поместится в доступной оперативной памяти? И сколько рабочих процессов требуется для обработки трафика, фактически поступающего в пул, чтобы запросы не ожидали ответа слишком долго? Высокое значение для pm.max_children не дает ответа ни на один из этих вопросов в отдельности.

Даже при наличии достаточного объёма памяти процессор, база данных или внешние службы могут ограничивать фактическую пропускную способность. В таком случае дополнительные рабочие процессы, хотя и позволяют выполнять больше задач PHP параллельно, могут одновременно усилить нагрузку на и без того медленную службу. Таким образом, значение пула является эксплуатационным ограничением, а не гарантией производительности.

Понимание работы менеджера процессов и очереди

Der Менеджер процессов определяет, когда PHP-FPM запускает рабочие процессы. При static заданное число процессов соответствует значению pm.max_children. Это позволяет хорошо планировать количество процессов, но при этом занимает ресурсы даже при низкой загрузке. Сам верхний предел по-прежнему должен соответствовать объему доступной памяти.

На сайте dynamic FPM настраивает количество процессов: дополнительно задаются начальное количество, а также минимальное и максимальное количество свободных рабочих процессов. При ondemand Рабочие процессы создаются только по мере необходимости и завершаются по истечении настроенного периода простоя. Это позволяет экономить ресурсы в редко используемых пулах; однако в случае внезапного пика нагрузки сначала необходимо создать новую вычислительную мощность.

Если все рабочие процессы заняты, дальнейшие запросы могут поступать в Очередь слушателей ожидать освобождения процесса. Статус FPM отображает, в частности, текущую и максимальную длину очереди. Однако однократное превышение максимального значения само по себе не свидетельствует о том, что пул в данный момент перегружен; для этого необходимо соотнести это значение со временем.

Более длинная очередь не создает дополнительных рабочих процессов и не ускоряет работу медленной базы данных. Она может временно принимать запросы, но лишь переносит время ожидания на этап, предшествующий обработке в PHP. Поэтому при выборе диспетчера процессов важно учитывать как типичную динамику нагрузки, так и последствия кратковременных пиков.

Правильная классификация рабочей памяти

Объем памяти, требуемый для одного рабочего процесса, невозможно достоверно определить, опираясь исключительно на ограничения конфигурации PHP. Для планирования более полезны данные о процессах, полученные в условиях соответствующей нагрузки. При этом имеет значение, рассматриваете ли вы объем резидентной памяти отдельного процесса или оцениваете потребление памяти всей группы рабочих процессов PHP-FPM.

RSS описывает резидентную память процесса. Если несколько рабочих процессов используют одни и те же страницы памяти, они могут входить в их соответствующие RSS. При сложении значений RSS всех рабочих процессов совместно используемые страницы в некоторых случаях могут фигурировать несколько раз; поэтому сумма не даёт точного представления о совместно занимаемой физической памяти.

PSS пропорционально распределяет совместно используемые страницы между участвующими процессами. Поэтому для планирования памяти для группы процессов сумма значений PSS часто оказывается более полезной, чем сумма значений RSS. Тем не менее это лишь моментальный срез: если количество процессов, совместно использующих страницы, изменяется, изменяются и соответствующие доли.

Рассмотрим несколько рабочих процессов как при типичных, так и при ресурсоемких запросах. Только что запущенный процесс или единичное среднее значение могут привести к недооценке будущих потребностей. Общий показатель PSS пула при различном количестве рабочих процессов и различных состояниях нагрузки помогает получить консервативную приблизительную оценку; экстраполяция на большее количество рабочих процессов остается неопределенной из-за изменчивости общих и частных долей.

PHP-memory_limit не является достоверным показателем общего объема памяти операционной системы, занимаемой процессом FPM, и не заменяет данное наблюдение. Общий доступ к памяти, например через OPcache, не следует автоматически вычитать из бюджета во второй раз, если он уже пропорционально учтён в используемом пуле PSS. Тем не менее необходимо учитывать другие службы и резерв.

Расчет объёма оперативной памяти и количества рабочих процессов

Отправной точкой служит фактически доступный объем оперативной памяти (RAM): на хосте — это объем памяти, доступный для служб, а в контейнере — фактический лимит памяти. От этого значения следует вычесть потребности операционной системы, веб-сервера, локальной базы данных (если таковая имеется) и других служб. В расчёт также следует включить другие пулы FPM и резерв на случай колебаний потребления.

Оставшаяся часть — это Бюджет бассейна. Для оценки нагрузки на рабочий узел проследи за суммой PSS рабочих узлов пула при различном количестве процессов и различных состояниях нагрузки. Учти как типичные запросы, так и конечные точки, требующие большого объема памяти. Разделите соответствующую сумму на рассматриваемое количество рабочих процессов и на основе нескольких наблюдений выведите осторожное приблизительное значение.

Приведенный ниже расчет является иллюстративным примером, а не результатом измерений. Принятые значения служат лишь для демонстрации метода расчета; они не являются рекомендацией для конкретного применения. Результат округляется до целого числа рабочих.

25 рабочих процессов не гарантируют безопасность. PSS распределяет совместно используемые страницы пропорционально и изменяется в зависимости от количества процессов, которые совместно используют эти страницы. Изменение состава запросов также может повлиять на потребность в частной памяти; поэтому прогноз следует сверять с наблюдаемым общим потреблением и установленным лимитом.

Если общий объем памяти, такой как OPcache, уже пропорционально учтён в используемой сумме PSS, не вычитай его повторно в виде фиксированной суммы как отдельную дополнительную статью. Тем не менее, предусмотрите резерв на доли памяти, которые не учтены в ваших расчётах. Особенно в случае ограничения на количество контейнеров в конечном итоге учитывается потребление всех процессов в пределах этого ограничения, а не только расчётная сумма рабочих процессов.

Один только недавно запущенный рабочий процесс в качестве основы не является достаточно показательным: возможно, он ещё не обработал ни одного сложного запроса. Поэтому сравните несколько моментов времени и зафиксируйте, какие конечные точки и сколько рабочих процессов участвовали в каждом случае. Так можно определить, будет ли выбранное приблизительное значение достоверным даже в менее благоприятных, но реалистичных условиях эксплуатации.

Оценка необходимого количества рабочих на основе запросов

Расчет объёма оперативной памяти (RAM) показывает, сколько рабочих процессов, по прогнозам, сможет в ней разместиться. В то же время для определения потребности учитывается, сколько PHP-запросов фактически поступает в рассматриваемый пул и как долго они занимают одного рабочего процесса. В качестве первого приближения принимается следующее соотношение: среднее количество одновременно занятых рабочих процессов равно количеству PHP-запросов в секунду, умноженному на среднее время занятости рабочего процесса в секундах.

Наглядный расчетный пример, не основанный на измерениях: при предполагаемой частоте 20 PHP-запросов в секунду и среднем времени обработки 0,25 секунды в среднем задействовано пять рабочих процессов. Это среднее значение за рассматриваемый период. Это не означает ни того, что всегда работает ровно пять процессов, ни того, что пяти процессов достаточно в качестве предельного значения пула для кратковременных пиковых нагрузок.

При подсчете количества запросов не следует без проверки учитывать все просмотры страниц. Если кэш возвращает много ответов без вызова PHP, эти попадания не создают нагрузки на пул. И наоборот, промахи кеша, авторизованные посетители и административные запросы могут временами вызывать больше нагрузки на PHP, чем можно было бы предположить, исходя из средних показателей за весь день.

Die Время занятости работника также включает время ожидания в ходе обработки, например, при обращении к базе данных или внешнему сервису. Его нельзя автоматически приравнивать к времени отклика, отображаемому в браузере. Согласно fastcgi_finish_request() PHP может уже завершить отправку ответа клиенту и при этом продолжить выполнение других задач в рабочем процессе.

Для обеспечения приемлемого времени ожидания необходим запас по сравнению со средней загрузкой. Каким именно должен быть этот запас, зависит, в частности, от колебаний нагрузки, медленных конечных точек и желаемого целевого значения времени отклика. Умножение пикового числа запросов в секунду на высокий процентиль задержки может служить осторожной проверкой сценария, но не является точным прогнозом состояния очереди.

Поэтому рассмотрите несколько периодов отдельно: кратковременный пик активности и спокойный ночной трафик могут давать такое же среднесуточное значение, как и более равномерная нагрузка, но предъявляют разные требования. Если время занятости увеличивается из-за медленного бэкэнда, то при одинаковой частоте прибытия растёт и среднее количество занятых работников. Таким образом, потребность зависит не только от интенсивности посещаемости.

Определить настройки пула на основе плана

Теперь сравните верхний предел, основанный на объеме оперативной памяти, с расчетной потребностью, включая запас. Если потребность не превышает этот предел, выберите осторожное начальное значение для pm.max_children, которому не обязательно использовать весь бюджет. В приведенном примере 25 будет расчетным пределом объема ОЗУ, но не обязательно оптимальной настройкой; процессор и бэкенд могут ограничить объем еще раньше.

Если расчетная потребность превышает предел оперативной памяти, увеличение этого предела не устранит конфликт: это может привести к перегрузке хоста или контейнера по памяти. И наоборот, слишком низкий предел может привести к задержкам в обработке запросов. В этом случае попробуйте, например, оптимизировать время выполнения или использование кэша, а также проверьте, не требуются ли дополнительные ресурсы или ограничение входящей нагрузки.

На сайте динамический Вы задаете не только верхний предел, но и начальное количество, а также минимальное и максимальное количество свободных рабочих процессов. Значения начального числа и резерва должны соответствовать ожидаемой нагрузке и оставаться в пределах верхнего предела. Слишком малый резерв мощностей может привести к необходимости запуска дополнительных процессов в случае внезапной нагрузки; с другой стороны, постоянное наличие большого количества свободных процессов приводит к излишнему потреблению ресурсов.

На сайте по требованию Рабочие процессы создаются только по мере необходимости; время простоя до их завершения настраивается отдельно. Это может быть целесообразно для редко используемых пулов, однако требует особого внимания в случае быстрого роста нагрузки. Здесь также ограничивает pm.max_children количество рабочих процессов пула, доступных одновременно.

Несколько веб-сайтов, размещенных на одном хосте, не получают независимо друг от друга весь объем свободной оперативной памяти. Распределите их возможные максимальные значения пула вместе с остальными службами и резервом. В случае необходимости может дополнительно применяться настроенное глобальное ограничение на количество процессов FPM, однако оно не заменяет ни отдельные бюджеты пулов, ни проверку мощности процессора и базы данных.

После внесения изменений проверяйте фактическую загрузку и время ожидания за соответствующие периоды, а не считайте начальное значение окончательным. В случае управляемого хостинга данные о процессах или настройки пулов могут быть недоступны напрямую; в таком случае используйте метрики и предоставленные провайдером параметры. Доступные настройки также зависят от версии PHP и операционной среды.

Мониторинг состояния FPM и памяти

Страница состояния FPM показывает, достаточно ли запланированных рабочих процессов при реальной нагрузке. Защити конечную точку состояния защищенный от публичного доступа: он может раскрывать конфиденциальные данные о запросах и ресурсах. Отдельно настроенный прослушиватель состояния может оставаться доступным даже при перегрузке основного пула; проверьте его доступность и настройки для вашей версии PHP и конфигурации веб-сервера.

Рассматривайте эти значения как временные ряды вместе с объемом запросов и временем отклика. Старое максимальное значение очереди не свидетельствует о текущей перегрузке; аналогично, в случае счетчиков их рост с момента последнего наблюдения является более показательным, чем просто общее значение. При этом учитывайте запуск пула или его перезапуск, в результате которых изменяется отчетный период.

Для известного FPM-рабочего процесса в системе Linux с доступным интерфейсом proc можно получить агрегированные значения памяти в режиме чтения. Замени PID по фактическому идентификатору процесса; для этого необходимы соответствующие права доступа. Повторите наблюдение для нескольких рабочих процессов и различных состояний нагрузки, вместо того чтобы определять постоянный размер пула на основе данных одного-единственного процесса.

cat /proc/PID/smaps_rollup

Анализ медленных запросов и очередей

В интернет-магазине может отображаться большое количество активных рабочих процессов, хотя исходным узким местом является не само выполнение PHP. Если запросы ожидают результатов медленных запросов к базе данных, рабочие процессы остаются занятыми в это время. При поступлении новых запросов очередь прослушивателей может увеличиваться, а время отклика — расти, даже если у процессора ещё есть резервы.

Увеличение предельного количества рабочих процессов в данной ситуации, возможно, позволит одновременно пропускать больше запросов в базу данных. Это может повлиять на Печать на сервере увеличить и ещё больше удлинить время ожидания. Поэтому, прежде чем повышать этот предел, сравните динамику загрузки FPM и длину очереди с нагрузкой на базу данных, медленными запросами и вызовами внешних служб.

Slowlog FPM помогает выявить длительные вызовы PHP: для запросов, превышающих настроенный порог, FPM может регистрировать трассировку. Она показывает точку выполнения и не является полным профилем всего запроса. Повторяющиеся участки можно сопоставить с продолжительностью запроса и метриками бэкэнда; Руководство по анализу журнала Slowlog PHP-FPM объясняется в дальнейшем анализе.

Таймаут также следует отделять от фактической пропускной способности. В nginx это обозначается fastcgi_read_timeout допустимый интервал между последовательными операциями чтения с сервера FastCGI, а не общую продолжительность запроса в целом. Более высокое значение может привести к более длительному ожиданию, но не создает дополнительных рабочих процессов и не ускоряет работу базы данных.

Ограничения пропускной способности и дальнейшие шаги

Если объёма оперативной памяти недостаточно для предполагаемых потребностей, увеличение значения параметра pm.max_children Не стоит игнорировать конфликт целей: дополнительные процессы также требуют памяти. Вместо этого проверьте, можно ли уменьшить количество запросов PHP или сократить время их обработки рабочими процессами. Выбор подходящей меры зависит от того, где возникает наблюдаемая нагрузка.

Более эффективно используемый кэш может перехватить повторные запросы, в то время как более быстрое выполнение PHP и доступ к базе данных позволяют раньше освобождать рабочие процессы. Соответствующие фоновые задачи можно вынести за пределы непосредственного пути запроса; однако даже эти задачи требуют собственных ресурсов. Ограничение нагрузки защищает бэкенд во время пиковых нагрузок, но может привести к тому, что запросы будут находиться в очереди или отклоняться.

Дополнительная оперативная память может позволить увеличить количество рабочих процессов, если память действительно является определяющим ограничивающим фактором. Если процессор, база данных или внешний сервис уже загружены до предела, необходимо также учитывать их пропускную способность. Поэтому одно лишь увеличение объёма памяти не гарантирует ни сокращения времени отклика, ни повышения пропускной способности.

Если объем памяти, требуемый отдельным рабочим процессам, превышает их время жизни, то pm.max_requests организовать их регулярную замену. Это может помочь при устранении утечек памяти в сторонних библиотеках, но не устраняет их причину. После внесения изменений продолжайте отслеживать использование памяти пула и поведение запросов, а не рассматривайте механизм перезапуска как замену поиска и устранения ошибок.

Для принятия более широкого архитектурного решения предлагается Сравнение NGINX Unit и PHP-FPM Контекст: модуль NGINX Unit заархивирован и больше не поддерживается. Независимо от выбранной архитектуры, изменения следует вносить на основе временные ряды Проверить: при схожем объёме запросов сравните очередь, загрузку рабочих процессов, объем памяти и время отклика. Так можно определить, действительно ли настройка устранила узкое место или просто перенесла его в другое место.