Налаштування PHP-FPM: використовуємо pm static для максимальної продуктивності

Невідредагована версія статті була спочатку опублікована на haydenjames.io і публікується тут із дозволу її автора.

Я в двох словах розповім, як найкраще налаштувати PHP-FPM, щоб збільшити пропускну здатність, знизити затримку та стабільніше використовувати процесорні ресурси та пам'ять. Типово рядок PM (process manager, менеджер процесів) в PHP-FPM має значення динамічнийа якщо у вас не вистачає пам'яті, то краще встановити на вимогу. Давайте порівняємо 2 варіанти управління на основі документації php.net і подивимося, чим від них відрізняється мій коханий статичний 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 з регулятором частоти процесора

Це може здатися офтопом, але я збираюся пов'язати це з темою налаштування PHP-FPM. У когось хоч раз не гальмував процесор — на ноутбуці, віртуальній машині або виділеному сервері. Чи пам'ятаєте масштабування частоти процесора? Ці параметри доступні для nix і Windows, можуть підвищити продуктивність та швидкість відгуку системи, якщо змінити параметр регулятора процесора з на вимогу на performance*. Цього разу давайте порівняємо описи та подивимося на подібності:

Governor = ondemand - динамічне масштабування частоти процесора в залежності від поточного навантаження. Різко переходить на максимальну частоту, а потім знижує її, коли збільшуються періоди простою.
Governor = conservative = динамічне масштабування частоти в залежності від поточного навантаження. Збільшує і зменшує частоту плавніше, ніж нанеобхідність.
Governor = performance - Частота завжди максимальна.

Подробиці див. В повний список параметрів регулятора частоти процесора.

Бачите схожість? Я хотів показати це порівняння, щоб переконати вас, що найкраще використовувати pm static для PHP-FPM.

Для регулятора процесора параметр продуктивність допомагає безпечно збільшити продуктивність, тому що майже повністю залежить від ліміту процесора сервера. Крім цього, звісно, ​​є ще такі фактори, як температура, заряд акумулятора (в ноутбуці) та інші побічні ефекти постійної роботи процесора на 100%. Налаштування performance забезпечує найшвидшу роботу процесора. Почитайте, наприклад, про параметрі force_turbo в Raspberry Pi, з яким панель RPi використовуватиме регулятор продуктивність, де поліпшення продуктивності буде помітніше через низьку тактову частоту ЦП.

Використання pm static для досягнення максимальної продуктивності сервера

Параметр PHP-FPM pm static багато в чому залежить від вільної пам'яті на сервері. Якщо пам'яті мало, краще вибрати на вимогу або динамічний. З іншого боку, якщо у вас є пам'ять, можна уникнути зайвих витрат менеджера PHP, встановивши pm статичний на максимальну ємність сервера. Іншими словами, якщо все добре підрахувати, потрібно встановити pm.static на максимальний обсяг процесів PHP-FPM, які можуть виконуватися, не створюючи проблем із нестачею пам'яті або кешу. Але не так високо, щоб перевантажити процесори і накопичити купу операцій PHP-FPM, які чекають на виконання.

На скріншоті вище сервер встановлено pm = static та pm.max_children = 100І це займає приблизно 10 ГБ з наявних 32. Зверніть увагу на виділені стовпці, тут і так все зрозуміло. На цьому скріншоті було приблизно 200 активних користувачів (більше 60 секунд) у Google Analytics. На цьому рівні приблизно 70% дочірніх процесів PHP-FPM все ще не діють. Це означає, що PHP-FPM завжди встановлений на максимальний обсяг ресурсів сервера, незалежно від поточного трафіку. Простоює процес чекає піків трафіку і реагує моментально. Вам не доводиться чекати, поки pm створить дочірні процеси, а потім завершить їх, коли закінчиться період pm.process_idle_timeout. Я встановив дуже велике значення для pm.max_requestsтому що це робочий сервер без витоків пам'яті в PHP. Ви можете встановити pm.max_requests = 0 зі static, якщо повністю впевнені у наявних та майбутніх скриптах PHP. Але краще перезапускати скрипти з часом. Встановіть велику кількість запитів, адже хочемо уникнути зайвих витрат pm. Наприклад, хоча б pm.max_requests = 1000 - Залежно від кількості pm.max_children та числа запитів за секунду.

На скріншоті показано команду Linux top, фільтрована по u (user) та імені користувача PHP-FPM. Показано лише перші 50 або близько того процесів (точно не рахував), але, по суті, top показує топ статистики, яка міститься у вікно терміналу. В цьому випадку з сортуванням % ЦП (%CPU). Щоб переглянути всі 100 процесів PHP-FPM, виконайте команду:

top -bn1 | grep php-fpm

Коли використовувати pm ondemand і dynamic

Якщо використовувати pm динамічний, виникають подібні помилки:

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 динамічний. Зазвичай використовується pm на вимогу, як радять у тому ж пості. Але це ще гірше, адже на вимогу завершує бездіяльні процеси до нуля, коли трафіку мало чи ні взагалі, і в результаті ви все одно будете мучитися з витратами при зміні трафіку. Якщо, звичайно, ви не встановили великий час очікування. І тоді краще вже використати pm.static + висока кількість pm.max_requests.

PM динамічний і особливо на вимогу можуть стати в нагоді, якщо у вас кілька пулів PHP-FPM. Наприклад, ви розміщуєте кілька облікових записів cPanel або кілька веб-сайтів у різних пулах. У мене є сервер, де, припустимо, 100+ облікових записів cpanel і приблизно 200 доменів, і pm.static або навіть dynamic мене б не врятував. Тут потрібен лише на вимогу, адже більше двох третин веб-сайтів отримують мало трафіку чи взагалі ніякого, а з на вимогу всі дочірні процеси відваляться, що заощадить нам безліч пам'яті! На щастя, розробники cPanel це помітили та встановили значення за замовчуванням на вимогу. Раніше, коли значення за замовчуванням було динамічний, PHP-FPM взагалі не підходив для загальних серверів. Багато хто використовував suPHP, тому що pm динамічний споживав пам'ять навіть при бездіючих пулах і облікових записах cPanel PHP-FPM. Швидше за все, при хорошому трафіку ви не розміщуватиметеся на сервері з великою кількістю пулів PHP-FPM (загальний хостинг).

Висновок

Якщо ви використовуєте PHP-FPM та трафік у вас серйозний, менеджери процесів на вимогу и динамічний для PHP-FPM будуть обмежувати пропускну здатність через властиві їм витрати. Вивчіть свою систему та налаштуйте процеси PHP-FPM відповідно до максимальної ємності сервера. Спочатку задайте pm.max_children залежно від максимального використання pm динамічний або на вимогу, а потім збільште це значення до рівня, де пам'ять і процесор працюватимуть без надмірного навантаження. Ви помітите, що з pm static, раз у вас все зберігається в пам'яті, піки трафіку згодом викликатимуть менше піків для процесора, а середні значення навантаження сервера та процесора вирівняються. Середній розмір процесу PHP-FPM залежить від веб-сервера і вимагає налаштування вручну, тому більш автоматизовані менеджери процесів динамічний и на вимогу - Більш популярні. Сподіваюся, стаття була корисною.

UPD Додана діаграма бенчмарку ab. Якщо процеси PHP-FPM знаходяться у пам'яті, продуктивність збільшується за рахунок споживання пам'яті, де вони сидять та чекають. Знайдіть собі оптимальний варіант.

Джерело: habr.com