HestiaCP PHP-FPM estas sub peza ŝarĝo? Dinamika retpaĝo 500 eraro? Ĉi tiu optimumigo efektiviĝos tuj!

Ĉu vi iam renkontis ĉi tiun situacion? Via retejo subite malrapidiĝas, aŭ eĉ ĵetas 500-eraron. Rekomenci PHP-FPM restarigas ĝin al normaleco , sed la problemo reaperas post iom da tempo? Estas nekredeble frustrante!

Kial tio okazas? Fakte, tio kutime estas kaŭzita de malĝusta agordo de la proceznaĝejo de PHP-FPM aŭ nesufiĉaj servilaj rimedoj . Hodiaŭ, ni plene optimumigos PHP-FPM sub HestiaCP por certigi la roksolidan stabilecon de via retejo!

La kerna kialo kial PHP-FPM estas troŝarĝita

PHP-FPM estas la procezadministrilo por PHP , respondeca pri la pritraktado de dinamikaj petoj. Malkonvena agordo povas konduki al:

• Servilaj rimedoj estas elĉerpitaj, igante PHP-FPM esti nekapabla respondi al novaj petoj ĝustatempe;
• Tro malmultaj procezoj, kiam trafiko subite pliiĝas, ĝi ne povas esti prilaborita ĝustatempe;
• Proceza uzado estas tro alta, igante la CPU-ŝarĝon eksplodi.

Kiel scii ĉu PHP-FPM estas troŝarĝita?

povas uzi top 或 htop Komando por vidi uzadon de CPU kaj memoro:

top -c

Se vi vidas procezajn informojn similajn al la sekvaj, tio signifas, ke PHP-FPM funkcias sub alta ŝarĝo:

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

Ĉu vi vidas ĉi tiujn procezojn uzi pli ol 70% de la CPU? Se tio okazas ofte, tiam certe io estas malĝusta kun via PHP-FPM!

Do, kiel ni povas optimumigi la PHP-FPM-agordon por ke la servilo ne plu estu troŝarĝita?

Optimumigo de PHP-FPM-proceza naĝejo (kerna parametroĝustigo)

Unue, malfermu php-fpm Agordaj dosieroj:

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

• *Ŝanĝu al via PHP-versio, ekzemple PHP8.5, kaj ŝanĝu ĝin al ĉi tio:/etc/php/8.3/fpm/pool.d/www.conf

Pridemandi la PHP-version agorditan de HestiaCP

v-list-web-domain user domain.com

Ekz-e:

v-list-web-domain abc chenweiliang.com

En la eligo, vi vidos ion kiel:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

Tio indikas, ke la retejo uzas PHP 8.5.

Ni rigardu vian PHP-FPM-agordon:

[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

Vi povas vidi ke via pm uzata estas ondemand,Kvankam ĝi povas redukti la uzadon de rimedoj dum neaktiva tempo, kiam trafiko subite pliiĝas, la procezo eble ne povos respondi ĝustatempe., rezultigante 500-eraron.

www.conf: La enkonstruita "universala rimeda provizo" de la sistemo

Post instalado de PHP-FPM, la sistemo aŭtomate provizos al vi... www.konf dokumento.
ĜiaPoziciigadoĜi estas tre simpla — ĝi estas nur defaŭlta proceznaĝejo kiu funkcias tuj, kutime ligita al... www-datumoj Uzanto-elŝuto.

Ĉi tiu tipo de naĝejo estas aparte taŭga por unu-lokaj medioj: la konfiguracio estas malpeza, kaj la parametroj estas ĉiuj ĝeneralaj ŝablonoj, kiel ekzemple:

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

Se vi gastigas nur unu retejon, vi povas uzi ĝin rekte kaj fidinde sen ia ajn ekstra ĝeno.

etNIFO.org.conf: Propra naĝejo

Post kiam vi funkciigas plurajn retejojn, vi ne povas teni ĉiujn ŝtopitaj en la saman naĝejon.
Je ĉi tiu punkto, HestiaCP aŭtomate kreos apartan naĝejon por ĉiu loko, ekzemple... etNIFO.org.konfSpecialigita pri domajnaj nomoj etufo.org servo.

La komuna maniero ludi estas:

• Ŝanĝi uzantojn kaj grupojn:user = etufo,group = etufo
• Sendependa monitorado:listen = /run/php/etufo.sock
• Alĝustigi la nombron de procezoj certigas roksolidan stabilecon eĉ sub alta samtempeco.
• Apartaj protokoldosieroj faciligas la problemsolvadon.

La avantaĝoj estas evidentaj: sekura izolado . Eĉ se unu retejo estas kompromitita, la aliaj restas netuŝitaj.

dummy.conf: ŝajndosiero

dummy.conf Temas kutime pri ekzemploj aŭ ŝablonoj provizitaj de la sistemo.
Ĝi fakte ne funkcios krom se vi ĝin permane modifos kaj ebligos.
Ĝia signifo pli similas al "funkciiga manlibro", kiu diras al vi kiel skribi novan naĝejkonfiguracion.

Kial dividi la naĝejon?

• 性Uzu malsamajn uzantojn por malsamaj retejoj por eviti konfliktajn permesojn.
• 性能优化La nombro da procezoj povas esti adaptita individue por ĉiu naĝejo, permesante flekseblajn alĝustigojn bazitajn sur trafika postulo.
• IzoloProtokoloj, eraroj kaj aŭskultaj adresoj estas ĉiuj apartigitaj, faciligante problemsolvadon.

Ekzemple, eĉ se www.conf kraŝos, etufo.org.conf ankoraŭ funkcios normale kaj ne paneigos la tutan servilon.

实际场景

• Unuloka servilo: www.conf sufiĉas.
• Multloka serviloĈiu retejo havas sian propran sendependan .conf-dosieron, ekzemple etufo.org.conf.
• dummy.confNur por referenco, ne rekomendinda.

Agorda Komparo

www.conf (defaŭlta naĝejo)

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

etufo.org.conf (Propra Naĝejo)

[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

La ĉefaj diferencoj estas: uzanta identeco, aŭskulta adreso, kaj nombro da procezoj.

1. Alĝustigu PHP-FPM-procezajn naĝejojn parametrojn

Se la agordo uzas dynamicJen metodo por antaŭkomenci iujn laborprocezojn kaj dinamike adapti ilin laŭ la petvolumo, kiu povas respondi pli rapide kiam la petvolumo subite pliiĝas.

Por retejoj kun certa kvanto da trafiko, oni rekomendas uzi pm = dynamicĈar ĝi povas konservi certan kvanton da neaktivaj procezoj kaj eviti 500 erarojn dum alta samtempeco.

Estas rekomendinde uzi ĝin nur kiam la alirvolumeno estas ekstreme malalta kaj la memorresursoj estas malvasta. pm = ondemand Por ŝpari rimedojn.

Sugestita al dynamic, kaj optimumigi pm.max_children Kaj aliaj parametroj:

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 后自动退出

Kial vi volas ŝanĝi ĝin tiel?

• pm = dynamic: Asignu procezojn pli flekseble por eviti petan atendon, kiu povas esti kaŭzita de postulo;
• pm.max_children = 16: Malhelpi 500 erarojn kaŭzitajn de tro malmultaj procezoj;
• pm.start_servers = 5: Evitu malrapidan procezan ekfunkciigon;
• pm.max_requests = 3000:Malhelpo de memorfuĝoj, recikli la procezon regule.

2. Limigu la ekzekuttempon de PHP-skriptoj por malhelpi longtempan okupadon

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

Tio malhelpas, ke certaj PHP-skriptoj, kiuj konsumas troan CPU-on, kraŝigu la servilon.

Post konservado, rekomencu la PHP-procezon:

sudo systemctl restart php8.3-fpm

Optimigu PHP-FPM bazitan sur VPS-agordo

Ekzemplo de VPS-agordo:

• Priskribo: VPS 3 NVMe
• Diska Spaco: 300 GB
• CPU-kernoj: 8
• RAM: 24 GB

Surbaze de via VPS-agordo ( 8 CPU-kernoj, 24 GB da RAM ), viaj servilaj rimedoj estas pli ol sufiĉaj. Por PHP-FPM, 24 GB da RAM permesas al vi agordi tre altan nombron da samtempaj procezoj.

En produktada medio, ni tipe asignas sufiĉe da memoro (ekzemple 8GB-12GB) por la sistemo mem, Apache-datumbazoj (kiel MySQL /MariaDB), kaj kaŝmemoroj (kiel Redis / Memcached ), lasante la ceterajn 12GB-16GB da memoro por esti plene asignitaj al PHP-FPM.

Bazite sur averaĝa memoruzado de 40MB-60MB por PHP-procezo , 1GB da memoro povas funkciigi proksimume 16-25 procezojn.

Jen alt-samtempeca, alt-efikeca FPM-agordo adaptita por vi , kiu povas multe plibonigi la kapaciton de WordPress kaj malhelpi ĝian kraŝon pro subitaj trafikpliiĝoj:

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

💡 Kial ĉi tiu agordo?

1. pm.max_children = 300Jen kerna optimumigo. Via antaŭa agordo de 50 procezoj estis tro konservativa por 24GB da memoro. Kiam oni renkontas subitajn pliiĝojn en trafiko (aŭ robotojn inundantajn la fonon), 50 procezoj estus tuj superŝarĝitaj, kaŭzante konektajn tempolimojn. Pligrandigi ĝin al 300 povas plibonigi la samtempecan prilaboran kapaciton de via servilo plurfoje.
2. pm.start_servers / `min_spare_serversĈar vi havas 8 CPU-kernojn, vi povas komence kaj normale konservi pli da neaktivaj procezoj, kio permesas al vi utiligi la plurkernan avantaĝon, tiel ke novaj petoj povas esti malfermitaj tuj sen atendi procezkreon.
3. pm.max_requests = 1000Pliigu de 500 al 1000. Via memoro estas granda, kaj procezoj ne bezonas esti rekomencitaj ofte. Pliigi ĝis 1000 povas redukti la CPU-konsumon kaŭzitan de ofta procezdetruo kaj kreado.

Vidu la malrapidan protokolon:

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

Post fari la ŝanĝojn, memoru rekomenci la servon PHP-FPM por ke la ŝanĝoj ekvalidu.

systemctl restart php8.5-fpm

Ebligu PHP-FPM-statomonitoradon por observi la progreson iam ajn

Ebligi PHP-FPM-procezmonitoradon permesas al vi vidi la nombron de aktivaj procezoj kaj la atendostaton de petoj iam ajn , malhelpante troŝarĝon de la servilo.

En php-fpm.conf Aldonita en:

pm.status_path = /status

Tiam, Nginx-agordo:

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;
}

Tiamaniere, vi povas http://yourdomain.com/status Rigardu PHP-FPM en ago!

Optimumu PHP-FPM protokolojn por rapide solvi problemojn

En php-fpm.conf Aldoni al:

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 的脚本记录到日志

Tiamaniere, kiam ajn 500-eraro okazas, vi povas rekte vidi la protokolon:

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

Vidu ĉu PHP raportas eraron, kiel ekzemple out of memory,script execution timeout Atendu

Rekomencu PHP-FPM regule por malhelpi memorfuĝojn

kapabla pasi cron Rekomencu PHP-FPM regule por malhelpi longdaŭrajn procezojn kaŭziMemorfluoj.

crontab -e

Aldonu la sekvan planitan taskon por aŭtomate rekomenci PHP-FPM je la 3-a matene ĉiutage:

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

Kio se la problemo daŭras? Plia optimumigo!

Se vi ankoraŭ foje renkontas eraron 500 post sekvado de la supraj optimumigoj , vi povas daŭrigi per la jenaj optimumigoj:

1. Ebligu OPcache por plibonigi PHP-ekzekutan efikecon

Se OPcache ankoraŭ ne estas ebligita, vi povas instali ĝin tiel (uzante Ubuntu kiel ekzemplon):

sudo apt install php8.5-opcache -y

Poste redakti php.ini:

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

• opcache.validigi_tempsignojn=0
• Malŝalti realtempan detektonReduktu dosiersisteman I/O-n kaj plibonigu rendimenton.

• Tamen, tio signifas, ke vi devas permane malplenigi la kaŝmemoron (rekomenci la PHP-servon) post modifo de PHP-dosieroj.

Post modifo de la agordo, vi devas rekomenci la PHP-servon por ke la ŝanĝoj ekvalidu.

sudo systemctl restart php<版本>-fpm

Efekto? PHP-paĝa ekzekutrapideco estis multe plibonigita!

2. Optimumigo de agordo de Nginx

Certiĝu, ke la rilataj parametroj de Nginx estas raciaj, kiel ekzemple fastcgi_read_timeout Alĝustigu ĝin taŭge por eviti ke PHP-skriptoj estu ĉesigitaj de Nginx pro longa ekzekuttempo:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Resumo: Optimumu PHP-FPM kaj la retejo ne plu kraŝos!

Kiajn ĝustigojn ni faris post ĉi tiu optimumigo?

✅ Optimumigo de la PHP-FPM-proceza naĝejo, uzi ondemandKaj optimumigi pm.max_children parametro;
✅ Limigante la ekzekuttempon de PHP-skriptoj, por malhelpi longtempan CPU-okupon;
✅ Ebligu PHP-FPM-monitoradon, rigardu la procezan ŝarĝon en reala tempo;
✅ Optimumigo de PHP-FPM-protokoloj, rapide solvi 500 erarojn;
✅ Rekomencu PHP-FPM regule, malhelpi memorajn fugojn;
✅ Ebligu OPcache, plibonigu PHP-ekzekutan efikecon;
✅ Optimumigo de Nginx-Agordo, por eviti problemojn pri tempodaŭro.

Post ĉi tiu optimumigo, la PHP-FPM-ŝarĝo multe malpliiĝos kaj la retejo-funkciado estos pli stabila! 🔥

Iru provi ĝin nun! 💪🚀

Se vi ankoraŭ volas lerni pli pri la agordo de PHP-FPM-ŝablonoj per HestiaCP, tiam ĉi tiu artikolo donos al vi pli profundan komprenon:

👉 HestiaCP Propra PHP-FPM Ŝablono: Sekretoj pri PHP 8.5-Optimigo de Rendimento ▼

🔗HestiaCP Propra PHP-FPM Ŝablono: Sekretoj pri PHP 8.5 Rendimento-Optimigo

En ĉi tiu enhavo, vi vidos:

• Alt-samtempecaj optimumigaj teknikoj: Kiel plibonigi respondrapidecon per racia proceza agordo.
• Sekureca izoliga solvo: Evitu riskojn de aliro inter retejoj kaj certigu kontostabilecon.
• Protokoloj kaj monitorado: Uzu malrapidajn protokolojn por trovi proplempunktojn kaj kontinue optimumigi retejan rendimenton.