Неотредактированная версия статьи была первоначально опубликована на HaydenJames.io и переиздана здесь с разрешения автора.
Давайте очень кратко рассмотрим, как лучше настроить PHP-FPM для высокой пропускной способности, низкой задержки и более стабильного использования процессора и памяти. По умолчанию в большинстве установок строка PM (диспетчер процессов) PHP-FPM установлена на динамический, и есть также общий совет использовать ondemand если вы страдаете от проблем с доступной памятью. Тем не менее, давайте сравним два варианта управления, основанные на документации php.net, а также сравним мой любимый для настройки большого трафика — static pm:
-
pm = dynamic : число дочерних процессов устанавливается динамически на основе следующих директив:
pm.max_children,pm.start_servers,pm.min_spare_servers,pm.max_spare_servers. -
pm = ondemand : процессы создаются по запросу по запросу, в отличие от динамического, где
pm.start_serversзапускается при запуске службы. -
pm = static : число дочерних процессов фиксируется с помощью
pm.max_children.
См. Полный список глобальных директив php-fpm.conf для получения дополнительной информации.
PHP-FPM Process Manager (PM) Сходства с CPUFreq Governor
Теперь это может показаться немного не по теме, но я надеюсь связать это с нашей темой по настройке PHP-FPM. Хорошо, в какой-то момент у всех нас были проблемы с процессором, будь то ноутбук, виртуальная машина или выделенный сервер. Помните масштабирование частоты процессора? ( Регулятор CPUFreq .) Эти настройки, доступные как в * nix, так и в Windows, могут повысить производительность и быстродействие системы, изменив настройку регулятора ЦП с ondemand на производительность . На этот раз давайте сравним описания и поищем сходства:
-
Governor = ondemand : динамически масштабирует частоту процессора в соответствии с текущей нагрузкой. Переходит на самую высокую частоту, а затем уменьшается по мере увеличения времени простоя.
-
Регулятор = консервативный : динамически масштабирует частоту в соответствии с текущей нагрузкой. Масштабирует частоту более постепенно, чем по требованию.
-
Регулятор = производительность : всегда запускайте процессор на максимальной частоте.
См. Полный список опций регулятора CPUFreq для получения дополнительной информации.
Заметили сходство? Сначала я хотел использовать это сравнение, чтобы найти лучший способ написать статью, в которой рекомендуется использовать pm static для PHP-FPM в качестве первого выбора.
При использовании регулятора ЦП настройка производительности является довольно безопасным приростом производительности, поскольку она почти полностью зависит от ограничения ЦП вашего сервера. Единственными другими факторами могут быть такие вещи, как нагрев, время автономной работы (ноутбук) и другие побочные эффекты от постоянной синхронизации частоты вашего процессора до 100%. После настройки производительности это действительно самая быстрая настройка для вашего процессора. Например, прочитайте о параметре force_turbo на Raspberry Pi, который заставляет вашу плату RPi использовать регулятор производительности, где повышение производительности более заметно из-за низких тактовых частот ЦП.
Использование «pm static» для достижения максимальной производительности вашего сервера
Статическая настройка PHP-FPM pm сильно зависит от того, сколько свободной памяти имеет ваш сервер. В основном, если вы страдаете от нехватки памяти на сервере, лучше использовать pm ondemand или dynamic. С другой стороны, если у вас есть доступная память, вы можете избежать значительных накладных расходов диспетчера процессов PHP (PM), установив pm static на максимальную емкость вашего сервера. Другими словами, когда вы выполняете математику, для pm.static должно быть установлено максимальное количество процессов PHP-FPM, которые могут работать без проблем с доступностью памяти или проблемами с кэшем. Кроме того, не так высоко, чтобы перегружать ЦП и иметь кучу ожидающих операций PHP-FPM.
На скриншоте выше этот сервер имеет pm = static и pm.max_children = 100 который использует максимум около 10 ГБ из 32 ГБ установленных. Обратите внимание на понятные выделенные столбцы. Во время этого скриншота в Google Analytics было около 200 «активных пользователей» (за последние 60 секунд). На этом уровне около 70% детей PHP-FPM по-прежнему бездействуют. Это означает, что PHP-FPM всегда настроен на максимальную емкость ресурсов вашего сервера независимо от текущего трафика. Бесполезные процессы остаются в сети, ожидая всплесков трафика и немедленно реагируя, вместо того, чтобы ждать в pm, чтобы порождать детей, а затем уничтожать их после истечения срока x pm.process_idle_timeout . Я установил чрезвычайно высокий уровень pm.max_requests потому что это pm.max_requests сервер без утечек памяти в PHP. Вы можете использовать pm.max_requests = 0 со static если вы уверены на 110% в своих текущих и будущих PHP-скриптах. Тем не менее, рекомендуется перезапустить сценарии со временем. Задайте для большого числа запросов большое количество, поскольку цель состоит в том, чтобы избежать накладных расходов pm. Так, например, как минимум pm.max_requests = 1000 зависимости от вашего числа pm.max_children и количества запросов в секунду.
Снимок экрана использует верхнюю часть Linux, отфильтрованную по опции ‘u’ (user) и имени пользователя PHP-FPM. Количество отображаемых процессов составляет только верхние 50 или около того (не считаются), но в основном top отображает верхнюю статистику, которая умещается в окне вашего терминала — в данном случае, отсортированная по% CPU. Для просмотра всех 100 процессов PHP-FPM вы можете использовать что-то вроде:
top -bn1 | grep php-fpm
Когда использовать pm ondemand и dynamic
Используя pm dynamic вы могли заметить ошибки, похожие на:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
Вы можете попытаться увеличить / откорректировать настройки и по-прежнему увидеть ту же ошибку, что и кто-то, описанный в этом сообщении об ошибке сервера В этом случае значение pm.min было слишком низким, и поскольку веб-трафик сильно колеблется в pm.min от провалов и скачков, использование pm dynamic может затруднить правильную настройку. Общий совет — использовать pm ondemand . Однако это еще хуже, потому что ondemand отключит незанятые процессы вплоть до 0, когда трафика практически нет, и тогда у вас будет столько же проблем с накладными расходами, сколько колеблется трафик — если, конечно, вы не установите время ожидания простоя чрезвычайно высокий … в этом случае вы должны просто использовать pm.static + высокий pm.max_requests .
Однако динамический PM и особенно ondemand могут спасти вас, когда у вас несколько пулов PHP-FPM. Например, размещение нескольких учетных записей cPanel или нескольких веб-сайтов в разных пулах. Например, у меня есть сервер с более чем 100 учетными записями cPanel и более 200 доменами, и для pm.static или даже для динамиков было бы невозможно работать хорошо. Хорошо работает только ondemand, поскольку более двух третей веб-сайтов практически не получают трафика. А с ondemand это означает, что все дети будут закрыты, что сэкономит тонны серверной памяти! К счастью, разработчики cPanel разобрались в этом, и теперь по умолчанию используется ondemand. Ранее с динамическим по умолчанию это делало PHP-FPM недоступным на занятых общих серверах. Многие используют suPHP из-за того, что pm динамически поглощает память даже на незанятых пулах / счетах cPanel PHP-FPM. Скорее всего, если вы получите хороший трафик, вы не будете размещены на сервере с большим количеством пулов PHP-FPM (общий хостинг).
Вывод
Когда дело доходит до PHP-FPM, когда вы начинаете обслуживать серьезный трафик, менеджеры процессов по требованию и динамические процессы для PHP-FPM могут ограничивать пропускную способность из-за внутренних издержек. Знайте свою систему и настройте процессы PHP-FPM в соответствии с максимальной мощностью вашего сервера. Начните с pm.max_children установленного на основе максимального использования pm dynamic или ondemand, а затем увеличивайте до уровня, при котором память и процессор могут обрабатываться, не перегружаясь. Вы заметите, что с pm static, поскольку вы храните все в памяти, скачки трафика со временем вызывают меньшие скачки ЦП, а нагрузка на ваш сервер и его средние значения будут более плавными. Средний размер вашего процесса PHP-FPM будет варьироваться в зависимости от веб-сервера, требующего ручной настройки, поэтому более популярные рекомендации — более автоматизированные служебные менеджеры процессов — динамические и по требованию. Надеюсь, что это была полезная статья.
Обновление: добавлен график сравнения A / B. Наличие процессов PHP-FPM в памяти помогает производительности за счет увеличения использования памяти, чтобы заставить их сидеть в ожидании. Найди свою настройку.
