Артицле Дирецтори
Да ли сте се икада сусрели са овом ситуацијом? Ваш веб сајт се изненада успорава или чак приказује грешку 500. Поновно покретање PHP-FPM-а га враћа у нормалу , али се проблем поново појављује после неког времена? То је невероватно фрустрирајуће!
Зашто се ово дешава? Заправо, ово је обично узроковано неправилном конфигурацијом PHP-FPM процеса или недовољним ресурсима сервера . Данас ћемо темељно оптимизовати PHP-FPM под HestiaCP-ом како бисмо осигурали изузетно стабилну стабилност вашег веб-сајта!
Основни разлог зашто је ПХП-ФПМ преоптерећен
PHP-FPM је менаџер процеса за PHP , одговоран за руковање динамичким захтевима. Неодговарајућа конфигурација може довести до:
- Ресурси сервера су исцрпљени, што доводи до тога да ПХП-ФПМ не може благовремено да одговори на нове захтеве;
- Премало процеса, када се промет нагло повећа, не може се на време обрадити;
- Употреба процеса је превисока, што доводи до експлозије оптерећења ЦПУ-а.

Како знати да ли је ПХП-ФПМ преоптерећен?
Можете користити top Или htop Команда за приказ употребе ЦПУ-а и меморије:
top -c
Ако видите информације о процесу сличне следећим, то значи да ПХП-ФПМ ради под великим оптерећењем:
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 Конфигурациони фајлови:
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
На пример:
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 датотека.
његовоПозиционирањеВеома је једноставно — то је само подразумевани скуп процеса који ради одмах по инсталацији, обично је повезан са... ввв-подаци Преузимање од стране корисника.
Ова врста базена је посебно погодна за окружења са једном локацијом: конфигурација је једноставна, а параметри су сви генерички шаблони, као што су:
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. Подесите ПХП-ФПМ параметре скупа процеса
Ако конфигурација користи 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. Ограничите време извршавања ПХП скрипти како бисте спречили дуготрајну заузетост
request_terminate_timeout = 30s ; 超过 30s 的 PHP 脚本自动终止
php_admin_value[memory_limit] = 128M ; 限制 PHP 进程最大内存占用
Ово спречава да одређене PHP скрипте које прекомерно троше CPU изазову пад сервера.
Након чувања, поново покрените ПХП процес:
sudo systemctl restart php8.3-fpmОптимизујте PHP-FPM на основу VPS конфигурације
Пример конфигурације VPS-а:
- Опис: VPS 3 NVMe
- Простор на диску: 300 ГБ
- ЦПУ језгра: 8
- РАМ: КСНУМКС МБ
На основу ваше VPS конфигурације ( 8 CPU језгара, 24 GB RAM-а ), ресурси вашег сервера су више него довољни. За PHP-FPM, 24 GB RAM-а вам омогућава да конфигуришете веома велики број истовремених процеса.
У продукцијском окружењу, обично додељујемо довољно меморије (рецимо 8-12 ГБ) за сам систем, Apache базе података (као што су MySQL /MariaDB) и кеш меморије (као што су Redis / Memcached ), остављајући преосталих 12-16 ГБ меморије да буде у потпуности додељено PHP-FPM-у.
На основу просечне потрошње меморије од 40MB-60MB по PHP процесу , 1GB меморије може да покрене приближно 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
💡 Зашто ова конфигурација?
pm.max_children = 300Ово је основна оптимизација. Ваша претходна конфигурација од 50 процеса била је превише конзервативна за 24 ГБ меморије. Приликом наглих пораста саобраћаја (или ботова који преплављују позадину), 50 процеса би било тренутно преоптерећено, што би изазвало прекиде везе. Повећање на 300 може неколико пута побољшати капацитет обраде истовремених података вашег сервера.pm.start_servers/ `min_spare_serversПошто имате 8 CPU језгара, у почетку и нормално можете задржати више неактивних процеса, што вам омогућава да искористите предност вишејезгарног процеса тако да се нови захтеви могу одмах отворити без чекања на креирање процеса.pm.max_requests = 1000Повећајте са 500 на 1000. Ваша меморија је велика и процеси не морају често да се рестартују. Повећање на 1000 може смањити потрошњу процесора узроковану честим уништавањем и креирањем процеса.
Погледајте дневник спорог рада:
tail -f /var/log/php8.5-fpm.log.slowtail -f /var/log/php8.4-fpm.log.slow
Након што направите измене, не заборавите да поново покренете PHP-FPM сервис да би промене ступиле на снагу.
systemctl restart php8.5-fpmОмогућите праћење статуса ПХП-ФПМ да бисте пратили напредак у било ком тренутку
Омогућавање праћења PHP-FPM процеса вам омогућава да видите број активних процеса и статус чекања захтева у било ком тренутку , спречавајући преоптерећење сервера.
Ин php-fpm.conf Додато у:
pm.status_path = /status
Затим, Нгинк конфигурација:
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.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
Погледајте да ли ПХП пријављује грешку, као нпр out of memory,script execution timeout Чекати.
Редовно рестартујте ПХП-ФПМ да бисте спречили цурење меморије
у стању да прође cron Редовно рестартујте ПХП-ФПМ да бисте спречили да изазову дуготрајни процесиМемори Леакс.
crontab -e
Додајте следећи заказани задатак да аутоматски поново покренете ПХП-ФПМ у 3 сата ујутро сваког дана:
0 3 * * * /usr/sbin/service php8.5-fpm restart
Шта ако проблем и даље постоји? Даља оптимизација!
Ако и даље повремено наилазите на грешку 500 након што сте пратили горе наведене оптимизације , можете наставити са следећим оптимизацијама:
1. Омогућите ОПцацхе да бисте побољшали ефикасност извршавања ПХП-а
Ако ОПцацхе још увек није омогућен, можете га инсталирати овако (користећи Убунту као пример):
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Ефекат? Брзина извршавања ПХП странице је знатно побољшана!
2. Оптимизација Нгинк конфигурације
Уверите се да су параметри везани за Нгинк разумни, као нпр fastcgi_read_timeout Прилагодите га на одговарајући начин како бисте избегли да Нгинк прекине ПХП скрипте због дугог времена извршавања:
fastcgi_read_timeout 60s;
client_max_body_size 100M;
Резиме: Оптимизујте ПХП-ФПМ и веб локација се више неће рушити!
Која прилагођавања смо извршили након ове оптимизације?
✅ Оптимизација ПХП-ФПМ скупа процеса,усе ondemandИ оптимизовати pm.max_children параметар;
✅ Ограничавање времена извршавања ПХП скрипти, да спречи дуготрајну заузетост процесора;
✅ Омогућите ПХП-ФПМ надгледање, преглед оптерећења процеса у реалном времену;
✅ Оптимизација ПХП-ФПМ дневника, брзо отклонити 500 грешака;
✅ Поново покрените ПХП-ФПМ редовно, спречи цурење меморије;
✅ Омогући ОПцацхе, побољшати ефикасност извршавања ПХП-а;
✅ Оптимизација Нгинк конфигурације, да бисте избегли проблеме са временским ограничењем.
Након ове оптимизације, ПХП-ФПМ оптерећење ће бити знатно смањено и рад веб странице ће бити стабилнији! 🔥
Иди пробај сада! 💪🚀
Ако сте и даље жељни да сазнате више о прилагођавању PHP-FPM шаблона помоћу HestiaCP-а, онда ће вам овај чланак пружити дубље разумевање:
👉 HestiaCP прилагођени PHP-FPM шаблон: Тајне оптимизације перформанси PHP 8.5 ▼
У овом садржају видећете:
- Технике оптимизације са високом конкурентношћу: Како побољшати брзину одзива кроз разумну конфигурацију процеса.
- Решење за безбедносну изолацију: Избегавајте ризике приступа са више локација и осигурајте стабилност налога.
- Записи и праћење: Користите споре записе да бисте лоцирали уска грла и континуирано оптимизовали перформансе веб странице.
Надам се да ће вам чланак „HestiaCP PHP-FPM Overload? Dynamic Webpage 500 Error? This Optimization Method Will Show Immediate Results!“ подељен на блогу Чен Веилианг ( https://www.chenweiliang.com/ ) бити од помоћи.
Слободно поделите линк овог чланка: https://www.chenweiliang.com/cwl-32512.html

