HestiaCP PHP-FPM перебуває під великим навантаженням? Помилка динамічної веб-сторінки 500? Ця оптимізація почне діяти негайно!

Ви коли-небудь стикалися з такою ситуацією? Ваш веб-сайт раптово сповільнюється або навіть видає помилку 500. Перезапуск PHP-FPM відновлює його нормальну роботу , але проблема знову з'являється через деякий час? Це неймовірно дратує!

Чому це відбувається? Насправді, це зазвичай спричинено неправильною конфігурацією пулу процесів PHP-FPM або недостатньою кількістю ресурсів сервера . Сьогодні ми ретельно оптимізуємо PHP-FPM під HestiaCP , щоб забезпечити надійну стабільність вашого веб-сайту!

Основна причина, чому PHP-FPM перевантажений

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

• Ресурси сервера вичерпано, через що PHP-FPM не може своєчасно відповідати на нові запити;
• Замало процесів, коли трафік раптово зростає, він не може бути оброблений вчасно;
• Використання процесу занадто велике, що спричиняє різке навантаження на ЦП.

Як визначити, чи PHP-FPM перевантажений?

можна використовувати top 或 htop Команда для перегляду використання ЦП і пам'яті:

top -c

Якщо ви бачите інформацію про процес, подібну до наведеної нижче, це означає, що PHP-FPM працює під високим навантаженням:

1669293 abc     20   0  790284 227880 185568 R  73.1   0.9   1:30.09 php-fpm: pool chenweiliang.com                                                    
1669522 abc     20   0  801924 224224 170236 R  69.9   0.9   0:59.01 php-fpm: pool chenweiliang.com

Ви бачите, що ці процеси використовують понад 70% ресурсів процесора? Якщо це трапляється часто, то з вашим PHP-FPM точно щось не так!

Отже, як ми можемо оптимізувати конфігурацію PHP-FPM, щоб сервер більше не перевантажувався?

Оптимізація пулу процесів PHP-FPM (коригування основних параметрів)

Спочатку відкрийте php-fpm Конфігураційні файли:

sudo nano /etc/php/*/fpm/pool.d/www.conf

• *Змініть версію PHP на вашу, наприклад, PHP8.5, і змініть її на цю:/etc/php/8.3/fpm/pool.d/www.conf

Запит версії PHP, встановленої HestiaCP

v-list-web-domain user domain.com

E.g:

v-list-web-domain abc chenweiliang.com

У вихідних даних ви побачите щось на зразок:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

Це вказує на те, що вебсайт використовує PHP 8.5.

Давайте розглянемо вашу конфігурацію PHP-FPM:

[chenweiliang.com]
listen = /run/php/php8.5-fpm-chenweiliang.com.sock
listen.owner = abc
listen.group = www-data
listen.mode = 0660

user = abc
group = abc

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s

Ви можете бачити, що ваш pm Той, що використовується ondemand,Незважаючи на те, що це може зменшити використання ресурсів під час простою, коли трафік раптово зростає, процес може не зреагувати вчасно., що призводить до помилки 500.

www.conf: Вбудований у систему «універсальний пул ресурсів»

Після встановлення PHP-FPM система автоматично надасть вам... www.conf файл.
ЙогоПозиціонуванняЦе дуже просто — це просто пул процесів за замовчуванням, який працює «з коробки», зазвичай підключений до... www-data Завантаження користувачем.

Цей тип пулу особливо підходить для середовищ з одним сайтом: конфігурація спрощена, а параметри є універсальними шаблонами, такими як:

user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm.max_children = 5

Якщо у вас розміщується лише один сайт, ви можете використовувати його безпосередньо та надійно без зайвих клопотів.

etНЛО.org.conf: Налаштовуваний пул

Якщо ви керуєте кількома сайтами, ви не можете тримати всіх в одному пулі.
На цьому етапі HestiaCP автоматично створить окремий пул для кожного сайту, наприклад... etНЛО.org.confСпеціалізується на доменних іменах etufo.org 服务。

Поширений спосіб гри:

• Змінити користувачів та групи:user = etufo,group = etufo
• Незалежний моніторинг:listen = /run/php/etufo.sock
• Регулювання кількості процесів забезпечує надійну стабільність навіть за високої паралельності.
• Окремі файли журналів роблять усунення несправностей зрозумілішим.

Переваги очевидні: безпечна ізоляція . Навіть якщо один сайт скомпрометовано, інші залишаються неушкодженими.

dummy.conf: файл-заповнювач

dummy.conf Зазвичай це приклади або шаблони, що надаються системою.
Він насправді не працюватиме, якщо ви не зміните та не ввімкнете його вручну.
Його значення радше схоже на «інструкцію з експлуатації», яка розповідає, як написати нову конфігурацію пулу.

Навіщо розділяти басейн?

• 性Використовуйте різних користувачів для різних сайтів, щоб уникнути конфлікту дозволів.
• 性能优化Кількість процесів можна налаштувати індивідуально для кожного пулу, що дозволяє гнучко налаштовувати їх залежно від потреб трафіку.
• ІзоляціяЖурнали, помилки та адреси прослуховування розділені, що спрощує усунення несправностей.

Наприклад, навіть якщо www.conf аварійно завершить роботу, etufo.org.conf все одно працюватиме нормально і не призведе до зупинки всього сервера.

Реальні сценарії

• Односайтовий серверwww.conf достатньо.
• Багатосайтовий серверКожен сайт має свій власний незалежний файл .conf, наприклад, etufo.org.conf.
• dummy.confТільки для довідки, не рекомендується.

Порівняння конфігурацій

www.conf (пул за замовчуванням)

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 5

etufo.org.conf (Налаштований пул)

[etufo.org]
user = etufo
group = etufo
listen = /run/php/etufo.sock
pm = dynamic
pm.max_children = 20
access.log = /var/log/php-fpm/etufo.access.log

Основні відмінності: ідентифікація користувача, адреса прослуховування та кількість процесів.

1. Налаштуйте параметри пулу процесів PHP-FPM

Якщо конфігурація використовує dynamicЦе метод попереднього запуску деяких робочих процесів та їх динамічного налаштування відповідно до обсягу запитів, що дозволяє швидше реагувати, коли обсяг запитів раптово збільшується.

Для веб-сайтів з певним обсягом трафіку рекомендується використовувати pm = dynamicОскільки він може підтримувати певну кількість простоїв процесів та уникати 500 помилок під час високої паралельності.

Рекомендується використовувати його лише тоді, коли обсяг доступу надзвичайно низький, а ресурси пам'яті обмежені. pm = ondemand Щоб заощадити ресурси.

Запропоновано dynamic, і оптимізувати pm.max_children І інші параметри:

pm = dynamic
pm.max_children = 16  ; 根据服务器资源调整，建议值：CPU 核心数 × 2
pm.start_servers = 4   ; 初始进程数，建议设为 max_children × 25%
pm.min_spare_servers = 2  ; 最小空闲进程数
pm.max_spare_servers = 7  ; 最大空闲进程数
pm.max_requests = 3000    ; 每个子进程处理完 3000 个请求后自动重启
pm.process_idle_timeout = 10s  ; 空闲进程 10s 后自动退出

Чому ви хочете це змінити?

• pm = dynamic: розподіляйте процеси більш гнучко, щоб уникнути очікування запиту, яке може бути викликане ondemand;
• pm.max_children = 16: запобігти 500 помилкам, викликаним занадто малою кількістю процесів;
• pm.start_servers = 5: уникайте повільного запуску процесу;
• pm.max_requests = 3000:Запобігання витоку пам'яті, регулярно переробляйте процес.

2. Обмежте час виконання сценаріїв PHP, щоб запобігти довгостроковій зайнятості

request_terminate_timeout = 30s  ; 超过 30s 的 PHP 脚本自动终止
php_admin_value[memory_limit] = 128M  ; 限制 PHP 进程最大内存占用

Це запобігає збоям сервера, пов'язаним з певними PHP-скриптами, які надмірно споживають ресурси процесора.

Після збереження перезапустіть процес PHP:

sudo systemctl restart php8.3-fpm

Оптимізація PHP-FPM на основі конфігурації VPS

Приклад конфігурації VPS:

• Опис: VPS 3 NVMe
• Місце на диску: 300 ГБ
• Ядра процесора: 8
• Оперативна пам'ять: 24 GB

Виходячи з конфігурації вашого VPS ( 8 ядер процесора, 24 ГБ оперативної пам'яті ), ресурсів вашого сервера більш ніж достатньо. Для PHP-FPM 24 ГБ оперативної пам'яті дозволяють налаштувати дуже велику кількість одночасних процесів.

У робочому середовищі ми зазвичай виділяємо достатньо пам'яті (скажімо, 8-12 ГБ) для самої системи, баз даних Apache (таких як MySQL /MariaDB) та кешів (таких як Redis / Memcached ), залишаючи решту 12-16 ГБ пам'яті повністю виділеними для PHP-FPM.

Виходячи зі середнього використання пам'яті 40-60 МБ на один PHP-процес , 1 ГБ пам'яті може запустити приблизно 16-25 процесів.

Нижче наведено конфігурацію FPM з високим рівнем паралельності, розроблену спеціально для вас , яка може значно покращити продуктивність WordPress та запобігти його збоям через раптове збільшення трафіку:

pm = dynamic

; 允许的最大 PHP 进程数（12GB 内存 / 40MB ≈ 300）
; 8核CPU搭配300个进程，可以轻松应对极高并发，且不至于让内存溢出
pm.max_children = 300

; 启动时创建的初始进程数（CPU核心数 * 4）
pm.start_servers = 32

; 维持的最小空闲进程数（服务器空闲时保留的进程，保证随时响应）
pm.min_spare_servers = 16

; 维持的最大空闲进程数（超过这个数量的空闲进程会被释放）
pm.max_spare_servers = 64

; 每个进程处理1000个请求后自动重启，高配置服务器可适当调大，有效防止WP插件内存泄露
pm.max_requests = 1000

; 单个请求最大执行时间，超时60秒强杀，防止死锁卡死
request_terminate_timeout = 60s

; 慢日志路径及触发阈值（请求超过5秒则记录，用于排查性能瓶颈）
slowlog = /var/log/php8.5-fpm.log.slow
request_slowlog_timeout = 5s

💡 Чому саме така конфігурація?

1. pm.max_children = 300Це базова оптимізація. Ваша попередня конфігурація з 50 процесів була занадто консервативною для 24 ГБ пам'яті. Під час раптових стрибків трафіку (або перевантаження фону ботами) 50 процесів миттєво перевантажувалися, що призводило до переривання часу з'єднання. Збільшення до 300 може в кілька разів покращити можливості паралельної обробки вашого сервера.
2. pm.start_servers / `мін_запасних_серверівОскільки у вас 8 ядер процесора, ви спочатку та зазвичай можете зберігати більше неактивних процесів, що дозволяє скористатися перевагою багатоядерності, щоб нові запити можна було відкривати миттєво, не чекаючи на створення процесу.
3. pm.max_requests = 1000Збільште значення з 500 до 1000. У вас великий обсяг пам'яті, і процеси не потрібно часто перезапускати. Збільшення до 1000 може зменшити споживання ресурсів процесора, спричинене частим знищенням та створенням процесів.

Перегляньте журнал повільного руху:

tail -f /var/log/php8.5-fpm.log.slow
tail -f /var/log/php8.4-fpm.log.slow

Після внесення змін не забудьте перезапустити службу PHP-FPM, щоб зміни набули чинності.

systemctl restart php8.5-fpm

Увімкніть моніторинг стану PHP-FPM, щоб відстежувати прогрес у будь-який час

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

在 php-fpm.conf Додано в:

pm.status_path = /status

Потім налаштування Nginx:

location /status {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

Таким чином, ви можете http://yourdomain.com/status Перевірте PHP-FPM у дії!

Оптимізуйте журнали PHP-FPM для швидкого вирішення проблем

在 php-fpm.conf 添加:

php_admin_value[error_log] = /var/log/php-fpm/error.log
php_admin_value[log_errors] = On
php_admin_value[error_reporting] = E_ALL
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s  ; 执行超过 5s 的脚本记录到日志

Таким чином, щоразу, коли виникає помилка 500, ви можете безпосередньо переглядати журнал:

tail -f /var/log/php-fpm/error.log

Подивіться, чи PHP повідомляє про помилку, наприклад out of memory,script execution timeout Зачекайте.

Регулярно перезапускайте PHP-FPM, щоб запобігти витокам пам’яті

здатний пройти cron Регулярно перезапускайте PHP-FPM, щоб запобігти довготривалим процесамВитоки пам'яті.

crontab -e

Додайте наступне заплановане завдання для автоматичного перезапуску PHP-FPM щодня о 3 ранку:

0 3 * * * /usr/sbin/service php8.5-fpm restart

Що робити, якщо проблема не зникає? Подальша оптимізація!

Якщо після виконання вищезазначених оптимізацій ви все ще час від часу стикаєтеся з помилкою 500 , ви можете продовжити з наступними оптимізаціями:

1. Увімкніть OPcache, щоб покращити ефективність виконання PHP

Якщо OPcache ще не ввімкнено, ви можете встановити його таким чином (на прикладі Ubuntu):

sudo apt install php8.5-opcache -y

потім редагувати php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.validate_timestamps=0

• opcache.validate_timestamps=0
• Вимкнути виявлення в реальному часіЗменште обсяг вводу-виводу файлової системи та покращте продуктивність.

• Однак це означає, що після зміни PHP-файлів вам потрібно буде вручну очистити кеш (перезапустити службу PHP).

Після зміни конфігурації необхідно перезапустити службу PHP, щоб зміни набули чинності.

sudo systemctl restart php<版本>-fpm

Ефект? Швидкість виконання PHP-сторінки значно покращено!

2. Оптимізація конфігурації Nginx

Переконайтеся, що пов’язані з Nginx параметри розумні, наприклад fastcgi_read_timeout Налаштуйте це належним чином, щоб уникнути завершення PHP-скриптів Nginx через тривалий час виконання:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Підсумок: оптимізуйте PHP-FPM, і веб-сайт більше не зависатиме!

Які корективи ми внесли після цієї оптимізації?

✅ Оптимізація пулу процесів PHP-FPM, використовувати ondemandІ оптимізувати pm.max_children параметр;
✅ Обмеження часу виконання скриптів PHP, щоб запобігти довгостроковій зайнятості ЦП;
✅ Увімкнути моніторинг PHP-FPM, переглядати завантаження процесу в реальному часі;
✅ Оптимізація журналів PHP-FPM, швидко усунути 500 помилок;
✅ Регулярно перезапускайте PHP-FPM, запобігати витоку пам'яті;
✅ Увімкніть OPcache, підвищити ефективність виконання PHP;
✅ Оптимізація конфігурації Nginx, щоб уникнути проблем з тайм-аутом.

Після цієї оптимізації навантаження на PHP-FPM значно зменшиться, а робота сайту буде стабільнішою! 🔥

Спробуйте зараз! 💪🚀

Якщо ви все ще хочете дізнатися більше про налаштування шаблонів PHP-FPM за допомогою HestiaCP, то ця стаття надасть вам глибше розуміння:

👉 Шаблон HestiaCP для користувача PHP-FPM: Секрети оптимізації продуктивності PHP 8.5 ▼

🔗Шаблон HestiaCP для PHP-FPM: секрети оптимізації продуктивності PHP 8.5

У цьому контенті ви побачите:

• Методи оптимізації з високим рівнем паралельності: Як покращити швидкість відгуку за допомогою розумної конфігурації процесу.
• Рішення для ізоляції безпеки: уникайте ризиків міжсайтового доступу та забезпечте стабільність облікового запису.
• Журнали та моніторинг: Використовуйте повільні журнали для виявлення вузьких місць та постійної оптимізації продуктивності веб-сайту.