PHP-FPM tuning: использование ‘pm static’ для максимальной производительности

Давайте очень быстро рассмотрим, как лучше всего настроить PHP-FPM для высокой пропускной способности, низкой задержки и более стабильного использования процессора и памяти. По умолчанию для большинства настроек PHP-FPM PM (process manager) установлена строка dynamic, и есть также общий совет использовать ondemand, если вы страдаете от проблем с доступной памятью. Однако давайте сравним два варианта управления на основе php.net документации:

pm = dynamic – количество дочерних процессов устанавливается динамически на основе следующих директив: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.

pm = ondemand – процессы появляются по требованию (по запросу, в отличие от dynamic, где pm.start_servers запускаются при запуске службы.

pm = static – количество дочерних процессов фиксируется pm.max_children.

См. Полный список глобальных директив php-fpm.conf для получения дополнительной информации.

PHP-FPM process manager (PM) сходство с CPUFreq Governor

Теперь это может показаться немного не по теме, но я надеюсь связать его с нашей темой настройки PHP-FPM. Хорошо, у всех нас были проблемы с медленным процессором в какой-то момент, будь то ноутбук, виртуальная машина или выделенный сервер. Помните масштабирование частоты процессора? (Регулятор CPUFreq) Эти настройки, доступные как в *nix, так и в Windows, могут повысить производительность и отзывчивость системы, изменив настройку регулятора процессора с ondemand на performance. На этот раз давайте сравним описания и поищем сходства:

Governor = ondemand – динамически масштабирует частоту процессора в соответствии с текущей нагрузкой. Переходит на самую высокую частоту, а затем масштабируется по мере увеличения времени простоя.

Governor = conservative = Масштабирует частоту динамически в соответствии с текущей нагрузкой. Масштабирует частоту более постепенно, чем ondemand.

Governor = performance – всегда запускайте процессор на максимальной частоте.

См. Полный список параметров регулятора CPUFreq для получения более подробной информации.

Обратите внимание на сходство? Сначала я хотел использовать это сравнение, чтобы найти лучший способ написать статью, в которой рекомендуется использовать pm static для PHP-FPM в качестве первого выбора.

С регулятором процессора настройка производительности является довольно безопасным повышением производительности, потому что она почти полностью зависит от предела процессора вашего сервера. Единственными другими факторами будут такие вещи, как тепло, время автономной работы (ноутбук) и другие побочные эффекты постоянной синхронизации частоты процессора до 100%. После установки на производительность это действительно самая быстрая настройка для вашего процессора. Например, прочитайте о настройке ‘force_turbo’ на Raspberry Pi, которая заставляет вашу плату RPi использовать регулятор производительности, где повышение производительности более заметно из — за низких тактовых частот процессора.

Использование ‘pm static’ для достижения максимальной производительности вашего сервера

Настройка PHP-FPM pm static сильно зависит от того, сколько свободной памяти имеет ваш сервер. В принципе, если вы страдаете от нехватки памяти сервера, то pm ondemand или dynamic могут быть лучшими вариантами. С другой стороны, если у вас есть доступная память, вы можете избежать большей части накладных расходов PHP process manager (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 установлен чрезвычайно высокий, потому что это производственный сервер без утечек памяти PHP. Вы можете использовать pm.max_requests = 0 со статикой, если у вас есть 110% уверенности в ваших текущих и будущих PHP-скриптах. Однако рекомендуется перезапускать скрипты с течением времени. Установите # запросов на большое число, чтобы избежать накладных расходов pm. Так, например, по крайней мере pm.max_requests = 1000 …в зависимости от вашего # pm.max_children и # запросов в секунду.

На скриншоте используется Linux top, отфильтрованный по опции ‘u’ (user) и имени пользователя PHP-FPM. Количество отображаемых процессов-это только ‘top’ 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

Вы можете попытаться изменить настройки и по-прежнему видеть ту же ошибку, что и кто-то описывает в этом сообщении Serverfault . В этом случае pm.min был слишком низким, и поскольку веб-трафик сильно колеблется с провалами и всплесками, использование pm dynamic может быть трудно правильно настроить. Общий совет-использовать pm ondemand, как и совет в этом же потоке поддержки. Однако это еще хуже, потому что ondemand завершит работу незанятых процессов вплоть до 0, когда трафика практически нет, и тогда у вас будет столько же накладных расходов, сколько колеблется трафик. Если, конечно, вы не установите тайм-аут ожидания чрезвычайно высоким. В этом случае вы должны просто использовать pm.static + высокий pm.max_requests.

Однако PM dynamic и особенно ondemand могут спасти вас, когда у вас есть несколько пулов PHP-FPM. Например, размещение нескольких учетных записей cPanel или нескольких веб-сайтов в разных пулах. Например, у меня есть сервер со 100 учетными записями cpanel и около 200 доменами, и для pm.static или даже dynamic было бы невозможно хорошо работать. Только ondemand работает хорошо, так как более двух третей веб-сайтов получают мало трафика, а с ondemand это означает, что все процессы будут отключены, экономя тонны памяти сервера! К счастью, разработчики cPanel поняли это и теперь по умолчанию используют ondemand. Многие будут использовать suPHP из-за pm dynamic, съедающего память даже на пулах/учетных записях cPanel PHP-FPM. Скорее всего, если вы получаете хороший трафик, вы не будете размещены на сервере с большим количеством пулов PHP-FPM (общий хостинг).

Заключение

Когда дело доходит до PHP-FPM, как только вы начинаете обслуживать серьезный трафик, ondemand и динамические менеджеры процессов для PHP-FPM могут ограничить пропускную способность из-за присущих им накладных расходов. Изучите свою систему и настройте процессы PHP-FPM в соответствии с максимальной пропускной способностью вашего сервера. Начните с pm.max_children, установленного на основе максимального использования pm dynamic или ondemand, а затем увеличьте до точки, где память и процессор могут обрабатывать, не перегружаясь. Вы заметите, что с pm static поскольку вы храните все в памяти, всплески трафика со временем вызывают меньше всплесков для процессора, а средняя загрузка вашего сервера и ЦП будут более плавными. Средний размер вашего процесса PHP-FPM будет варьироваться в зависимости от веб-сервера, требующего ручной настройки, поэтому более автоматизированные менеджеры процессов – dynamic и ondemand – являются более популярными рекомендациями. Надеюсь, это была полезная статья.

График сравнения

Наличие процессов PHP-FPM в памяти помогает производительности за счет увеличения использования памяти, когда они находятся в ожидании.

Источник

Добавить комментарий