HestiaCP PHP-FPM знаходзіцца пад вялікай нагрузкай? Памылка дынамічнай вэб-старонкі 500? Гэтая аптымізацыя ўступіць у сілу неадкладна!

Вы калі-небудзь сутыкаліся з такой сітуацыяй?Доступ да вэб-сайта раптоўна запаволіўся або нават прывёў да памылкі 500. Пасля перазапуску PHP-FPM ён вярнуўся да нармальнага стану., але праз некаторы час праблема з'яўляецца зноў? Гэта так расчароўвае!

Чаму так адбываецца?На самай справе, гэта звычайнаПул працэсаў PHP-FPM настроены няправільна, або рэсурсаў сервера недастаткова.выклікана. Сёння мы зоймемся грунтоўнай аптымізацыяй HestiaCP PHP-FPM пад капотам робіць вэб-сайт стабільным, як камень!

Асноўная прычына, чаму PHP-FPM перагружаны

PHP-FPM - гэта aДыспетчар працэсаў, які адказвае за апрацоўку дынамічных запытаў. Калі канфігурацыя неразумная, гэта можа прывесці да:

• Рэсурсы сервера вычарпаныя, у выніку чаго 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.3, і зменіце яе на наступнае:/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.3

Гэта азначае, што сайт выкарыстоўвае PHP 8.3.

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

[chenweiliang.com]
listen = /run/php/php8.3-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-дадзеныя 用户下跑。

这种池子特别适合单站点环境：配置轻量，参数都是通用模板，比如：

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

如果你只托管一个站点，直接用它就能稳稳当当，不需要额外折腾。

etUfo.org.conf：专属定制池

一旦你要跑多个站点，就不能再让大家挤在同一个池里了。
这时候HestiaCP会自动给每个站点单独开一个池，比如 etUfo.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: Размяркоўвайце працэсы больш гнутка, каб пазбегнуць чакання запыту, якое можа быць выклікана па патрабаванні;
• 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, каб адсочваць прагрэс у любы час

Уключыце маніторынг працэсаў 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.3-fpm restart

Што рабіць, калі праблема не знікне? Далейшая аптымізацыя!

Калі вы ўсё яшчэ прытрымліваецеся вышэйапісанай аптымізацыіЧасам узнікаюць 500 памылак, вы можаце працягнуць наступныя аптымізацыі:

1. Уключыце OPcache для павышэння эфектыўнасці выканання PHP

Калі OPcache яшчэ не ўключаны, вы можаце ўсталяваць яго так (на прыкладзе Ubuntu):

sudo apt install php8.3-opcache -y

Затым адрэдагуйце php.ini:

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

Эфект? Хуткасць выканання старонак 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 значна знізіцца, а праца сайта стане больш стабільнай! 🔥

Паспрабуйце зараз! 💪🚀