HestiaCP PHP-FPM is onder swaar las? Dinamiese webbladsy 500-fout? Hierdie optimalisering sal onmiddellik in werking tree!

Het jy al ooit hierdie situasie teëgekom? Jou webwerf word skielik stadiger, of gee selfs 'n 500-fout. As jy PHP-FPM herbegin, word dit weer normaal , maar die probleem verskyn weer na 'n rukkie? Dis ongelooflik frustrerend!

Waarom gebeur dit? Dit word eintlik gewoonlik veroorsaak deur onbehoorlike PHP-FPM-prosespoelkonfigurasie of onvoldoende bedienerhulpbronne . Vandag sal ons PHP-FPM deeglik onder HestiaCP optimaliseer om jou webwerf se rotsvaste stabiliteit te verseker!

Die kernrede waarom PHP-FPM oorlaai is

PHP-FPM is die prosesbestuurder vir PHP , verantwoordelik vir die hantering van dinamiese versoeke. Onvanpaste konfigurasie kan lei tot:

• Bedienerhulpbronne is uitgeput, wat veroorsaak dat PHP-FPM nie betyds op nuwe versoeke kan reageer nie;
• Te min prosesse, wanneer verkeer skielik toeneem, kan dit nie betyds verwerk word nie;
• Prosesgebruik is te hoog, wat veroorsaak dat die SVE-lading ontplof.

Hoe om te weet of PHP-FPM oorlaai is?

kan gebruik top 或 htop Opdrag om SVE en geheuegebruik te sien:

top -c

As jy prosesinligting soortgelyk aan die volgende sien, beteken dit dat PHP-FPM onder hoë las loop:

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

Sien jy dat hierdie prosesse meer as 70% van die SVE gebruik? As dit gereeld gebeur, dan is daar beslis iets fout met jou PHP-FPM!

So, hoe kan ons die PHP-FPM-konfigurasie optimaliseer sodat die bediener nie meer oorlaai word nie?

PHP-FPM proses swembad optimalisering (kern parameter aanpassing)

Eerstens, oop php-fpm Konfigurasie lêers:

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

• *Verander na jou PHP-weergawe, soos PHP8.5, en verander dit na hierdie:/etc/php/8.3/fpm/pool.d/www.conf

Vra die PHP-weergawe wat deur HestiaCP gestel is

v-list-web-domain user domain.com

Bv:

v-list-web-domain abc chenweiliang.com

In die uitset sal jy iets sien soos:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

Dit dui daarop dat die webwerf PHP 8.5 gebruik.

Kom ons kyk na jou PHP-FPM-konfigurasie:

[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

Jy kan sien dat jou pm Die een wat gebruik word is ondemand,Alhoewel dit hulpbrongebruik tydens ledige tyd kan verminder, kan die proses dalk nie betyds reageer wanneer verkeer skielik toeneem nie., wat lei tot 'n 500-fout.

www.conf: Die stelsel se ingeboude "universele hulpbronpoel"

Nadat PHP-FPM geïnstalleer is, sal die stelsel jou outomaties voorsien van 'n... www.konf lêer.
syPosisioneringDis baie eenvoudig—dis net 'n standaard prosespoel wat reguit werk, gewoonlik gekoppel aan... www-data Gebruiker aflaai.

Hierdie tipe poel is veral geskik vir enkelperseel-omgewings: die konfigurasie is liggewig, en die parameters is almal generiese sjablone, soos:

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

As jy slegs een webwerf aanbied, kan jy dit direk en betroubaar gebruik sonder enige ekstra moeite.

etUFO.org.conf: Pasgemaakte poel

Sodra jy verskeie webwerwe bedryf, kan jy nie almal in dieselfde poel ingeprop hou nie.
Op hierdie stadium sal HestiaCP outomaties 'n aparte poel vir elke webwerf skep, byvoorbeeld... etUFO.org.confGespesialiseerd vir domeinnaame etufo.org 服务.

Die algemene manier om te speel is:

• Verander gebruikers en groepe:user = etufo,group = etufo
• Onafhanklike monitering:listen = /run/php/etufo.sock
• Die aanpassing van die aantal prosesse verseker rotsvaste stabiliteit, selfs onder hoë gelyktydigheid.
• Afsonderlike loglêers maak probleemoplossing duideliker.

Die voordele is voor die hand liggend: veilige isolasie . Selfs al word een webwerf gekompromitteer, bly die ander onaangeraak.

dummy.conf: dummy-lêer

dummy.conf Dit is gewoonlik voorbeelde of sjablone wat deur die stelsel verskaf word.
Dit sal nie eintlik loop tensy jy dit handmatig wysig en aktiveer nie.
Die betekenis daarvan is meer soos 'n "gebruikershandleiding", wat jou vertel hoe om 'n nuwe swembadkonfigurasie te skryf.

Waarom die swembad verdeel?

• 安全 性Gebruik verskillende gebruikers vir verskillende webwerwe om botsende toestemmings te vermy.
• 性能优化Die aantal prosesse kan individueel vir elke poel aangepas word, wat buigsame aanpassings gebaseer op verkeersaanvraag moontlik maak.
• IsolasieLogs, foute en luisteradresse word almal geskei, wat probleme oplos makliker maak.

Byvoorbeeld, selfs al val www.conf vas, sal etufo.org.conf steeds normaal loop en nie die hele bediener afbring nie.

实际场景

• Enkel-werf bedienerwww.conf is genoeg.
• MultiwerfbedienerElke webwerf het sy eie onafhanklike .conf-lêer, soos etufo.org.conf.
• dummy.confSlegs vir verwysing, nie aanbeveel nie.

Konfigurasievergelyking

www.conf (standaardpoel)

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

etufo.org.conf (Aangepaste Poel)

[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

Die belangrikste verskille is: gebruikersidentiteit, luisteradres en aantal prosesse.

1. Pas PHP-FPM proses swembad parameters aan

As die konfigurasie gebruik dynamicDit is 'n metode om sommige werkprosesse vooraf te begin en hulle dinamies aan te pas volgens die versoekvolume, wat vinniger kan reageer wanneer die versoekvolume skielik toeneem.

Vir webwerwe met 'n sekere hoeveelheid verkeer, word dit aanbeveel om te gebruik pm = dynamicOmdat dit 'n sekere hoeveelheid onaktiewe prosesse kan handhaaf en 500 foute tydens hoë gelyktydigheid kan vermy.

Dit word aanbeveel om dit slegs te gebruik wanneer die toegangsvolume uiters laag is en die geheuebronne beperk is. pm = ondemand Om hulpbronne te bespaar.

Voorgestel om dynamic, en optimaliseer pm.max_children En ander parameters:

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

Hoekom wil jy dit so verander?

• pm = dynamic: Wys prosesse meer buigsaam toe om versoekewagting te vermy wat deur onaanvraag veroorsaak kan word;
• pm.max_children = 16: Voorkom 500 foute wat deur te min prosesse veroorsaak word;
• pm.start_servers = 5: Vermy stadige proses opstart;
• pm.max_requests = 3000:Voorkom geheuelekkasies, herwin die proses gereeld.

2. Beperk die uitvoeringstyd van PHP-skrifte om langtermynbesetting te voorkom

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

Dit verhoed dat sekere PHP-skripte wat oormatige SVE verbruik, die bediener laat ineenstort.

Nadat u gestoor het, herbegin die PHP-proses:

sudo systemctl restart php8.3-fpm

Optimaliseer PHP-FPM gebaseer op VPS-konfigurasie

VPS-konfigurasievoorbeeld:

• Beskrywing: VPS 3 NVMe
• Skyfspasie: 300 GB
• SVE-kerns: 8
• RAM: 24 GB

Gebaseer op jou VPS-konfigurasie ( 8 SVE-kerns, 24 GB RAM ), is jou bedienerhulpbronne meer as voldoende. Vir PHP-FPM laat 24 GB RAM jou toe om 'n baie hoë aantal gelyktydige prosesse te konfigureer.

In 'n produksiemgewing ken ons tipies genoeg geheue toe (sê 8GB-12GB) vir die stelsel self, Apache-databasisse (soos MySQL /MariaDB), en caches (soos Redis / Memcached ), wat die oorblywende 12GB-16GB geheue ten volle aan PHP-FPM toewys.

Gebaseer op 'n gemiddelde geheuegebruik van 40MB-60MB per PHP-proses , kan 1GB geheue ongeveer 16-25 prosesse uitvoer.

Die volgende is 'n hoë-gelyktydige, hoë-prestasie FPM-konfigurasie wat vir jou aangepas is , wat WordPress se kapasiteit aansienlik kan verbeter en kan verhoed dat dit ineenstort as gevolg van skielike verkeersstygings:

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

💡 Waarom hierdie konfigurasie?

1. pm.max_children = 300Dit is 'n kernoptimalisering. Jou vorige konfigurasie van 50 prosesse was te konserwatief vir 24 GB geheue. Wanneer jy skielike stygings in verkeer teëkom (of robotte wat die agtergrond oorstroom), sal 50 prosesse onmiddellik oorweldig word, wat verbindingstyd-uitkeer veroorsaak. Deur dit tot 300 te verhoog, kan jou bediener se gelyktydige verwerkingsvermoë verskeie kere verbeter word.
2. pm.start_servers / `min_spaar_bedienersOmdat jy 8 SVE-kerne het, kan jy aanvanklik en normaalweg meer onaktiewe prosesse behou, wat jou toelaat om voordeel te trek uit die multikernvoordeel sodat nuwe versoeke onmiddellik oopgemaak kan word sonder om te wag vir prosesskepping.
3. pm.max_requests = 1000Verhoog van 500 na 1000. Jou geheue is groot, en prosesse hoef nie gereeld herbegin te word nie. Deur dit na 1000 te verhoog, kan die SVE-verbruik wat veroorsaak word deur gereelde prosesvernietiging en -skepping, verminder word.

Bekyk die stadige logboek:

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

Nadat u die veranderinge aangebring het, onthou om die PHP-FPM-diens te herbegin sodat die veranderinge in werking kan tree.

systemctl restart php8.5-fpm

Aktiveer PHP-FPM-statusmonitering om tred te hou met die vordering te eniger tyd

Deur PHP-FPM-prosesmonitering te aktiveer, kan jy die aantal aktiewe prosesse en die wagstatus van versoeke te eniger tyd sien , wat oorlading van die bediener voorkom.

在 php-fpm.conf Bygevoeg in:

pm.status_path = /status

Dan, Nginx-konfigurasie:

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

Op hierdie manier kan jy http://yourdomain.com/status Kyk na PHP-FPM in aksie!

Optimaliseer PHP-FPM-logboeke om probleme vinnig op te los

在 php-fpm.conf Voeg by:

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

Op hierdie manier, wanneer 'n 500-fout voorkom, kan u die log direk bekyk:

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

Kyk of PHP 'n fout rapporteer, soos out of memory,script execution timeout 等.

Herbegin PHP-FPM gereeld om geheuelekkasies te voorkom

in staat is om te slaag cron Herbegin PHP-FPM gereeld om te verhoed dat langlopende prosesse veroorsaakGeheue lek.

crontab -e

Voeg die volgende geskeduleerde taak by om PHP-FPM outomaties elke dag om 3:XNUMX te herbegin:

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

Wat as die probleem voortduur? Verdere optimalisering!

Indien u steeds af en toe 'n 500-fout teëkom nadat u die bogenoemde optimaliserings gevolg het , kan u met die volgende optimaliserings voortgaan:

1. Aktiveer OPcache om PHP uitvoering doeltreffendheid te verbeter

As OPcache nog nie geaktiveer is nie, kan jy dit so installeer (gebruik Ubuntu as 'n voorbeeld):

sudo apt install php8.5-opcache -y

Redigeer dan php.ini:

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

• opcache.validate_timestamps=0
• Deaktiveer intydse opsporingVerminder lêerstelsel I/O en verbeter werkverrigting.

• Dit beteken egter dat jy die kasgeheue handmatig moet skoonmaak (die PHP-diens herbegin) nadat jy PHP-lêers gewysig het.

Nadat u die konfigurasie gewysig het, moet u die PHP-diens herbegin sodat die veranderinge in werking kan tree.

sudo systemctl restart php<版本>-fpm

Effek? PHP-bladsy uitvoering spoed is aansienlik verbeter!

2. Nginx konfigurasie optimalisering

Maak seker dat Nginx-verwante parameters redelik is, soos fastcgi_read_timeout Pas dit gepas aan om te voorkom dat PHP-skrifte deur Nginx beëindig word as gevolg van lang uitvoeringstyd:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Opsomming: Optimaliseer PHP-FPM en die webwerf sal nie meer ineenstort nie!

Watter aanpassings het ons gemaak na hierdie optimalisering?

✅ Optimalisering van die PHP-FPM-prosespoel,gebruik ondemandEn optimaliseer pm.max_children parameter;
✅ Beperk die uitvoeringstyd van PHP-skrifte, om langtermyn CPU-besetting te voorkom;
✅ Aktiveer PHP-FPM-monitering, bekyk die proseslading intyds;
✅ Optimaliseer PHP-FPM logs, spoor 500 foute vinnig op;
✅ Herbegin PHP-FPM gereeld, voorkom geheue lekkasies;
✅ Aktiveer OPcache, verbeter PHP uitvoering doeltreffendheid;
✅ Optimaliseer Nginx-konfigurasie, om uittelprobleme te vermy.

Na hierdie optimalisering sal die PHP-FPM-lading aansienlik verminder word en die webwerf-werking sal meer stabiel wees! 🔥

Gaan probeer dit nou! 💪🚀

As jy steeds gretig is om meer te leer oor die aanpassing van PHP-FPM-sjablone met HestiaCP, dan sal hierdie artikel jou 'n dieper begrip gee:

👉 HestiaCP Pasgemaakte PHP-FPM Sjabloon: PHP 8.5 Prestasie-optimalisering Geheime ▼

🔗HestiaCP Pasgemaakte PHP-FPM Sjabloon: PHP 8.5 Prestasie-optimalisering Geheime

In hierdie inhoud sal jy sien:

• Hoë-gelyktydigheidsoptimeringstegnieke: Hoe om reaksiespoed te verbeter deur redelike proseskonfigurasie.
• Sekuriteitsisolasie-oplossing: Vermy toegangsrisiko's tussen webwerwe en verseker rekeningstabiliteit.
• Logboeke en monitering: Gebruik stadige logboeke om knelpunte op te spoor en webwerfprestasie voortdurend te optimaliseer.