Kas HestiaCP PHP-FPM on suure koormuse all? Dünaamilise veebilehe tõrge 500? See optimeerimine jõustub kohe!

Kas olete kunagi sellise olukorraga kokku puutunud? Teie veebisait aeglustub ootamatult või annab isegi 500 vea. PHP-FPM-i taaskäivitamine taastab selle normaalseks , kuid probleem ilmub mõne aja pärast uuesti? See on uskumatult masendav!

Miks see juhtub? Tegelikult on selle põhjuseks tavaliselt vale PHP-FPM protsesside kogumi konfiguratsioon või ebapiisavad serveriressursid . Täna optimeerime PHP-FPM-i põhjalikult HestiaCP all, et tagada teie veebisaidi kivikõva stabiilsus!

Peamine põhjus, miks PHP-FPM on ülekoormatud

PHP-FPM on PHP protsessihaldur , mis vastutab dünaamiliste päringute käsitlemise eest. Sobimatu konfiguratsioon võib põhjustada:

• Serveri ressursid on ammendatud, mistõttu PHP-FPM ei suuda uutele päringutele õigeaegselt vastata;
• Liiga vähe protsesse, kui liiklus järsult suureneb, ei saa seda õigeaegselt töödelda;
• Protsessi kasutus on liiga kõrge, põhjustades protsessori koormuse plahvatuse.

Kuidas teha kindlaks, kas PHP-FPM on ülekoormatud?

saab kasutada top Või htop Käsk protsessori ja mälukasutuse vaatamiseks:

top -c

Kui näete järgmisega sarnast protsessiteavet, tähendab see, et PHP-FPM töötab suure koormuse all:

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

Kas näete, et need protsessid kasutavad rohkem kui 70% protsessori võimsusest? Kui see juhtub sageli, siis on teie PHP-FPM-iga kindlasti midagi valesti!

Niisiis, kuidas saaksime PHP-FPM konfiguratsiooni optimeerida nii, et server ei oleks enam ülekoormatud?

PHP-FPM protsessikogumi optimeerimine (põhiparameetrite reguleerimine)

Esiteks, avage php-fpm Konfiguratsioonifailid:

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

• *Mine oma PHP versioonile, näiteks PHP8.5, ja muuda see selliseks:/etc/php/8.3/fpm/pool.d/www.conf

Päringu esitamine HestiaCP poolt määratud PHP versiooni kohta

v-list-web-domain user domain.com

E.g:

v-list-web-domain abc chenweiliang.com

Väljundis näete midagi sellist:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

See näitab, et veebisait kasutab PHP 8.5.

Vaatame teie PHP-FPM konfiguratsiooni:

[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

Näete, et teie pm Üks kasutatud on ondemand,Kuigi see võib jõudeajal ressursikasutust vähendada, ei pruugi protsess liikluse järsu suurenemise korral õigeaegselt reageerida., mille tulemuseks on 500 viga.

www.conf: Süsteemi sisseehitatud "universaalne ressursivaru"

Pärast PHP-FPM-i installimist pakub süsteem teile automaatselt... www.conf dokument.
sellePositsioneerimineSee on väga lihtne – see on lihtsalt vaikimisi protsesside kogum, mis töötab kohe karbist võttes ja on tavaliselt seotud... www-andmed Kasutaja allalaadimine.

Seda tüüpi bassein sobib eriti hästi ühe asukohaga keskkondadesse: konfiguratsioon on kerge ja parameetrid on kõik üldised mallid, näiteks:

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

Kui majutate ainult ühte saiti, saate seda otse ja usaldusväärselt kasutada ilma lisaprobleemideta.

etufo.org.conf: Kohandatud rühm

Kui sul on juba mitu saiti, ei saa sa kõiki samasse basseini mahutada.
Sel hetkel loob HestiaCP automaatselt iga saidi jaoks eraldi basseini, näiteks... etufo.org.confSpetsialiseeritud domeeninimedele etufo.org 服务。

Levinud mängimisviis on:

• Kasutajate ja rühmade muutmine:user = etufo,group = etufo
• Sõltumatu jälgimine:listen = /run/php/etufo.sock
• Protsesside arvu reguleerimine tagab kivikõva stabiilsuse isegi suure samaaegsuse korral.
• Eraldi logifailid muudavad tõrkeotsingu selgemaks.

Eelised on ilmsed: turvaline isolatsioon . Isegi kui üks sait satub ohtu, jäävad teised puutumata.

dummy.conf: näivfail

mannekeen.conf Need on tavaliselt süsteemi pakutavad näited või mallid.
See ei käivitu tegelikult enne, kui te seda käsitsi muudate ja lubate.
Selle tähtsus on pigem nagu "kasutusjuhend", mis ütleb teile, kuidas kirjutada uus basseini konfiguratsioon.

Miks basseini jagada?

• 安全 性Konfliktsete õiguste vältimiseks kasutage erinevate saitide jaoks erinevaid kasutajaid.
• 性能优化Protsesside arvu saab iga basseini jaoks eraldi reguleerida, mis võimaldab paindlikke kohandusi vastavalt liiklusnõudlusele.
• IsolatsioonLogid, vead ja kuulamisaadressid on kõik eraldatud, mis lihtsustab tõrkeotsingut.

Näiteks isegi kui www.conf peaks kokku jooksma, töötab etufo.org.conf ikkagi normaalselt ega takista terve serveri tööd.

实际场景

• Ühe saidiga serverPiisab www.conf-ist.
• Mitme saidiga serverIgal saidil on oma iseseisev .conf-fail, näiteks etufo.org.conf.
• mannekeen.confAinult viitamiseks, ei ole soovitatav.

Konfiguratsiooni võrdlus

www.conf (vaikimisi bassein)

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

etufo.org.conf (kohandatud rühm)

[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

Peamised erinevused on: kasutaja identiteet, kuulamisaadress ja protsesside arv.

1. Reguleerige PHP-FPM protsessikogumi parameetreid

Kui konfiguratsioon kasutab dynamicSee on meetod mõnede tööprotsesside eelkäivitamiseks ja nende dünaamiliseks kohandamiseks vastavalt päringute mahule, mis suudab kiiremini reageerida, kui päringute maht järsult suureneb.

Teatud liiklusmahuga veebisaitide puhul on soovitatav kasutada pm = dynamicSest see suudab säilitada teatud hulga jõudeolekus protsesse ja vältida 500 viga suure samaaegsuse korral.

Soovitatav on seda kasutada ainult siis, kui juurdepääsumaht on äärmiselt väike ja mäluressursid on piiratud. pm = ondemand Ressursside säästmiseks.

Soovitatav dynamicja optimeerida pm.max_children Ja muud parameetrid:

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

Miks sa tahad seda niimoodi muuta?

• pm = dynamic: jaotage protsesse paindlikumalt, et vältida päringu ootamist, mis võib olla põhjustatud nõudmisel;
• pm.max_children = 16: Väldi 500 viga, mis on põhjustatud liiga vähestest protsessidest;
• pm.start_servers = 5: vältige protsessi aeglast käivitamist;
• pm.max_requests = 3000:Mälulekke vältimine, töötlege protsessi regulaarselt.

2. Piirake PHP-skriptide täitmisaega, et vältida pikaajalist hõivatust

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

See hoiab ära teatud PHP-skriptide poolt serveri krahhimise, mis tarbivad liiga palju protsessorit.

Pärast salvestamist taaskäivitage PHP protsess:

sudo systemctl restart php8.3-fpm

Optimeeri PHP-FPM-i VPS-i konfiguratsiooni põhjal

VPS-i konfiguratsiooni näide:

• Kirjeldus: VPS 3 NVMe
• Kettaruum: 300 GB
• Protsessori tuumad: 8
• RAM: 24 GB

Teie VPS-i konfiguratsiooni ( 8 protsessori tuuma, 24 GB muutmälu ) põhjal on teie serveriressursid enam kui piisavad. PHP-FPM-i jaoks võimaldab 24 GB muutmälu konfigureerida väga suurt hulka samaaegseid protsesse.

Tootmiskeskkonnas eraldame tavaliselt piisavalt mälu (näiteks 8–12 GB) süsteemile endale, Apache andmebaasidele (nt MySQL / MariaDB) ja vahemäludele (nt Redis / Memcached ), jättes ülejäänud 12–16 GB mälu täielikult PHP-FPM-ile eraldamiseks.

Lähtudes keskmisest mälukasutusest 40 MB–60 MB PHP protsessi kohta , saab 1 GB mäluga käitada umbes 16–25 protsessi.

Järgnev on teie jaoks kohandatud suure samaaegsuse ja jõudlusega FPM-konfiguratsioon , mis aitab oluliselt parandada WordPressi mahtu ja vältida selle krahhi ootamatute liikluse kasvude tõttu:

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

💡 Miks see konfiguratsioon?

1. pm.max_children = 300See on põhiline optimeerimine. Teie eelmine 50 protsessiga konfiguratsioon oli 24 GB mälu jaoks liiga konservatiivne. Järsu liikluse suurenemise (või taustal töötavate robotite) korral ülekoormatuks 50 protsessi koheselt, põhjustades ühenduse ajalõpusid. Selle suurendamine 300-ni võib teie serveri samaaegse töötlemise võimsust mitu korda parandada.
2. pm.start_servers / `min_spare_serversKuna teil on 8 protsessori tuuma, saate algselt ja tavaliselt säilitada rohkem jõudeolevaid protsesse, mis võimaldab teil ära kasutada mitmetuumalise tehnoloogia eelist, nii et uusi päringuid saab koheselt avada ilma protsesside loomist ootamata.
3. pm.max_requests = 1000Suurendage arvu 500-lt 1000-le. Teie mälu on suur ja protsesse ei pea sageli taaskäivitama. Suurendamine arvuni 1000 võib vähendada protsessori koormust, mis on põhjustatud sagedasest protsesside hävitamisest ja loomisest.

Vaata aegluse logi:

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

Pärast muudatuste tegemist ärge unustage PHP-FPM teenust taaskäivitada, et muudatused jõustuksid.

systemctl restart php8.5-fpm

Lubage PHP-FPM oleku jälgimine, et igal ajal edenemist jälgida

PHP-FPM protsesside jälgimise lubamine võimaldab teil igal ajal vaadata aktiivsete protsesside arvu ja päringute ooteolekut , vältides serveri ülekoormust.

在 php-fpm.conf Lisatud:

pm.status_path = /status

Seejärel Nginxi konfiguratsioon:

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

Sel viisil saate http://yourdomain.com/status Vaadake PHP-FPM-i tegevuses!

Probleemide kiireks tõrkeotsinguks optimeerige PHP-FPM logisid

在 php-fpm.conf Lisa:

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

Sel viisil saate iga 500 tõrke ilmnemisel logi otse vaadata:

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

Vaadake, kas PHP teatab veast, nt out of memory,script execution timeout Oota.

Mälulekke vältimiseks taaskäivitage PHP-FPM regulaarselt

võimeline mööduma cron Taaskäivitage PHP-FPM regulaarselt, et vältida pikaajalisi protsesseMälu lekked.

crontab -e

PHP-FPM-i automaatseks taaskäivitamiseks iga päev kell 3 öösel lisage järgmine ajastatud toiming:

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

Mis siis, kui probleem püsib? Edasine optimeerimine!

Kui pärast ülaltoodud optimeeringute järgimist ilmneb ikka aeg-ajalt 500. veakood , võite jätkata järgmiste optimeeringutega:

1. PHP täitmise tõhususe parandamiseks lubage OPcache

Kui OPcache pole veel lubatud, saate selle installida järgmiselt (kasutades Ubuntut näitena):

sudo apt install php8.5-opcache -y

Seejärel redigeeri php.ini:

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

• opcache.validate_timestamps=0
• Keela reaalajas tuvastamineVähendage failisüsteemi sisend-/väljundvõimsust ja parandage jõudlust.

• See tähendab aga seda, et pärast PHP-failide muutmist peate vahemälu käsitsi tühjendama (PHP-teenuse taaskäivitama).

Pärast konfiguratsiooni muutmist peate muudatuste jõustumiseks PHP-teenuse taaskäivitama.

sudo systemctl restart php<版本>-fpm

Mõju? PHP lehe täitmise kiirus on oluliselt paranenud!

2. Nginxi konfiguratsiooni optimeerimine

Veenduge, et Nginxiga seotud parameetrid oleksid mõistlikud, näiteks fastcgi_read_timeout Kohandage seda sobivalt, et vältida PHP-skriptide lõpetamist Nginxi poolt pika täitmisaja tõttu:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Kokkuvõte: Optimeerige PHP-FPM ja veebisait ei jookse enam kokku!

Milliseid kohandusi oleme pärast seda optimeerimist teinud?

✅ PHP-FPM protsessikogumi optimeerimine, kasutage ondemandJa optimeerida pm.max_children parameeter;
✅ PHP skriptide täitmise aja piiramine, et vältida CPU pikaajalist hõivamist;
✅ Luba PHP-FPM jälgimine, vaadake protsessi koormust reaalajas;
✅ PHP-FPM logide optimeerimine, kiiresti 500 vea tõrkeotsing;
✅ Taaskäivitage PHP-FPM regulaarselt, vältige mälulekkeid;
✅ Luba OPcache, parandada PHP täitmise tõhusust;
✅ Nginxi konfiguratsiooni optimeerimine, et vältida ajalõpu probleeme.

Pärast seda optimeerimist väheneb PHP-FPM koormus oluliselt ja veebisaidi töö on stabiilsem! 🔥

Mine proovi kohe! 💪🚀

Kui soovid endiselt rohkem teada saada PHP-FPM mallide kohandamise kohta HestiaCP abil, annab see artikkel sulle sügavama arusaama:

👉 HestiaCP kohandatud PHP-FPM mall: PHP 8.5 jõudluse optimeerimise saladused ▼

🔗HestiaCP kohandatud PHP-FPM mall: PHP 8.5 jõudluse optimeerimise saladused

Selles sisus näete:

• Suure samaaegsuse optimeerimise tehnikad: kuidas parandada reageerimiskiirust mõistliku protsessikonfiguratsiooni abil.
• Turvalisuse isoleerimise lahendus: Vältige saidiüleseid juurdepääsuriske ja tagage konto stabiilsus.
• Logid ja jälgimine: Kasutage aeglaseid logisid kitsaskohtade leidmiseks ja veebisaidi jõudluse pidevaks optimeerimiseks.