Vai HestiaCP PHP-FPM ir liela slodze? Dinamiskās tīmekļa lapas 500 kļūda? Šī optimizācija stāsies spēkā nekavējoties!

Vai esat kādreiz saskārušies ar šādu situāciju? Jūsu vietne pēkšņi palēninās vai pat izmet 500 kļūdu. PHP-FPM restartēšana atjauno to normālā stāvoklī , bet problēma pēc kāda laika atkal parādās? Tas ir neticami nomācoši!

Kāpēc tas notiek? Patiesībā to parasti izraisa nepareiza PHP-FPM procesu kopas konfigurācija vai nepietiekami servera resursi . Šodien mēs rūpīgi optimizēsim PHP-FPM, izmantojot HestiaCP , lai nodrošinātu jūsu vietnes nevainojamo stabilitāti!

Galvenais iemesls, kāpēc PHP-FPM ir pārslogots

PHP-FPM ir PHP procesu pārvaldnieks , kas atbild par dinamisko pieprasījumu apstrādi. Nepareiza konfigurācija var izraisīt:

• Servera resursi ir izsmelti, izraisot PHP-FPM nespēju laicīgi atbildēt uz jauniem pieprasījumiem;
• Pārāk maz procesu, kad pēkšņi palielinās satiksme, to nevar savlaicīgi apstrādāt;
• Procesa lietojums ir pārāk augsts, izraisot CPU slodzes eksploziju.

Kā noteikt, vai PHP-FPM ir pārslogots?

var izmantot top Vai htop Komanda, lai skatītu CPU un atmiņas lietojumu:

top -c

Ja redzat tālāk norādītajam līdzīgu procesa informāciju, tas nozīmē, ka PHP-FPM darbojas ar lielu slodzi:

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

Vai redzat, ka šie procesi izmanto vairāk nekā 70% centrālā procesora jaudas? Ja tas notiek bieži, tad noteikti kaut kas nav kārtībā ar jūsu PHP-FPM!

Tātad, kā mēs varam optimizēt PHP-FPM konfigurāciju, lai serveris vairs nebūtu pārslogots?

PHP-FPM procesu kopas optimizācija (pamatparametru pielāgošana)

Vispirms atveriet php-fpm Konfigurācijas faili:

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

• *Pārslēdzieties uz savu PHP versiju, piemēram, PHP8.5, un nomainiet to uz šo:/etc/php/8.3/fpm/pool.d/www.conf

Vaicājiet HestiaCP iestatīto PHP versiju

v-list-web-domain user domain.com

E. g .:

v-list-web-domain abc chenweiliang.com

Izvadē jūs redzēsit kaut ko līdzīgu:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

Tas norāda, ka vietne izmanto PHP 8.5.

Apskatīsim jūsu PHP-FPM konfigurāciju:

[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

Jūs varat redzēt, ka jūsu pm Izmantotais ir ondemand,Lai gan tas var samazināt resursu izmantošanu dīkstāves laikā, pēkšņi pieaugot satiksmei, process var nespēt reaģēt laikā., kā rezultātā tiek parādīta kļūda 500.

www.conf: Sistēmas iebūvētais "universālais resursu kopums"

Pēc PHP-FPM instalēšanas sistēma automātiski nodrošinās jums... www.conf dokumentu.
TāsPozicionēšanaTas ir ļoti vienkārši — tas ir tikai noklusējuma procesu kopums, kas darbojas uzreiz pēc instalēšanas, parasti pievienots... www-dati Lietotāja lejupielāde.

Šāda veida pūls ir īpaši piemērots vienas vietnes videi: konfigurācija ir viegla, un visi parametri ir vispārīgas veidnes, piemēram:

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

Ja jūs mitināt tikai vienu vietni, varat to izmantot tieši un droši, bez jebkādām papildu problēmām.

etNLO.org.conf: Pielāgots pūls

Kad pārvaldāt vairākas vietnes, vairs nevarat visus turēt vienā grupā.
Šajā brīdī HestiaCP automātiski izveidos atsevišķu kopu katrai vietnei, piemēram... etNLO.org.confSpecializējas domēnu vārdiem etufo.org 服务。

Izplatītākais spēles veids ir šāds:

• Mainīt lietotājus un grupas:user = etufo,group = etufo
• Neatkarīga uzraudzība:listen = /run/php/etufo.sock
• Procesu skaita pielāgošana nodrošina nevainojamu stabilitāti pat augstas vienlaicības apstākļos.
• Atsevišķi žurnālfaili padara problēmu novēršanu skaidrāku.

Ieguvumi ir acīmredzami: droša izolācija . Pat ja viena vietne tiek apdraudēta, pārējās paliek neskartas.

dummy.conf: fiktīvs fails

manekens.conf Tie parasti ir sistēmas nodrošināti piemēri vai veidnes.
Tas faktiski nedarbosies, ja vien to manuāli nemodificēsiet un neiespējosiet.
Tās nozīme vairāk līdzinās "lietošanas rokasgrāmatai", kurā norādīts, kā uzrakstīt jaunu baseina konfigurāciju.

Kāpēc sadalīt baseinu?

• 安全 性Lai izvairītos no konfliktējošām atļaujām, dažādām vietnēm izmantojiet dažādus lietotājus.
• 性能优化Procesu skaitu var pielāgot individuāli katram pūlam, nodrošinot elastīgas korekcijas atkarībā no datplūsmas pieprasījuma.
• IzolācijaŽurnāli, kļūdas un klausīšanās adreses ir atdalītas, tādējādi atvieglojot problēmu novēršanu.

Piemēram, pat ja www.conf avarē, etufo.org.conf joprojām darbosies normāli un neizslēgs visu serveri.

实际场景

• Vienas vietnes serverisPietiek ar www.conf.
• Vairāku vietņu serverisKatrai vietnei ir savs neatkarīgs .conf fails, piemēram, etufo.org.conf.
• manekens.confTikai uzziņai, nav ieteicams.

Konfigurācijas salīdzinājums

www.conf (noklusējuma pūls)

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

etufo.org.conf (pielāgots pūls)

[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

Galvenās atšķirības ir: lietotāja identitāte, klausīšanās adrese un procesu skaits.

1. Pielāgojiet PHP-FPM procesu pūla parametrus

Ja konfigurācija izmanto dynamicŠī ir metode, kas ļauj iepriekš sākt dažus darba procesus un dinamiski pielāgot tos atbilstoši pieprasījumu apjomam, kas var ātrāk reaģēt, kad pieprasījumu apjoms pēkšņi palielinās.

Tīmekļa vietnēm ar noteiktu apmeklētāju skaitu ieteicams izmantot pm = dynamicJo tas var uzturēt noteiktu daudzumu dīkstāves procesu un izvairīties no 500 kļūdām augstas vienlaicības laikā.

Ieteicams to izmantot tikai tad, ja piekļuves apjoms ir ārkārtīgi mazs un atmiņas resursi ir ierobežoti. pm = ondemand Lai taupītu resursus.

Ieteicams dynamicun optimizēt pm.max_children Un citi parametri:

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

Kāpēc jūs vēlaties to mainīt šādi?

• pm = dynamic: elastīgāk piešķiriet procesus, lai izvairītos no pieprasījuma gaidīšanas, ko var izraisīt pieprasījums;
• pm.max_children = 16: Novērst 500 kļūdas, ko izraisa pārāk maz procesu;
• pm.start_servers = 5: Izvairieties no lēnas procesa palaišanas;
• pm.max_requests = 3000:Atmiņas noplūdes novēršana, regulāri pārstrādājiet procesu.

2. Ierobežojiet PHP skriptu izpildes laiku, lai novērstu ilgstošu noslogojumu

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

Tas novērš servera avāriju, ko izraisa daži PHP skripti, kas patērē pārmērīgu procesora jaudu.

Pēc saglabāšanas restartējiet PHP procesu:

sudo systemctl restart php8.3-fpm

Optimizējiet PHP-FPM, pamatojoties uz VPS konfigurāciju

VPS konfigurācijas piemērs:

• Apraksts: VPS 3 NVMe
• Diska vieta: 300 GB
• CPU kodoli: 8
• RAM: 24 GB

Pamatojoties uz jūsu VPS konfigurāciju ( 8 centrālā procesora kodoli, 24 GB RAM ), jūsu servera resursi ir vairāk nekā pietiekami. PHP-FPM gadījumā 24 GB RAM ļauj konfigurēt ļoti lielu skaitu vienlaicīgu procesu.

Ražošanas vidē mēs parasti piešķiram pietiekami daudz atmiņas (piemēram, 8–12 GB) pašai sistēmai, Apache datubāzēm (piemēram, MySQL /MariaDB) un kešatmiņām (piemēram, Redis / Memcached ), atstājot atlikušos 12–16 GB atmiņas pilnībā piešķiršanai PHP-FPM.

Balstoties uz vidējo atmiņas izmantošanu 40 MB–60 MB apmērā uz vienu PHP procesu , 1 GB atmiņas var darbināt aptuveni 16–25 procesus.

Tālāk ir sniegta jums pielāgota augstas vienlaicības un veiktspējas FPM konfigurācija , kas var ievērojami uzlabot WordPress jaudu un novērst tā avārijas pēkšņas datplūsmas pieauguma dēļ:

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

💡 Kāpēc šāda konfigurācija?

1. pm.max_children = 300Šī ir pamata optimizācija. Jūsu iepriekšējā 50 procesu konfigurācija bija pārāk konservatīva 24 GB atmiņai. Pēkšņas datplūsmas pieauguma gadījumā (vai botu pārpludināšanas fonā gadījumā) 50 procesi tiktu nekavējoties pārslogoti, izraisot savienojuma taimautus. Palielinot to līdz 300, var vairākkārt uzlabot servera vienlaicīgās apstrādes jaudu.
2. pm.start_servers / `min_spare_serversTā kā jums ir 8 centrālā procesora kodoli, sākotnēji un parasti varat saglabāt vairāk dīkstāvē esošu procesu, kas ļauj izmantot vairāku kodolu priekšrocības, lai jaunus pieprasījumus varētu atvērt nekavējoties, negaidot procesa izveidi.
3. pm.max_requests = 1000Palieliniet no 500 līdz 1000. Jūsu atmiņa ir liela, un procesi nav bieži jārestartē. Palielinot līdz 1000, var samazināt centrālā procesora patēriņu, ko izraisa bieža procesu iznīcināšana un izveide.

Skatīt lēno žurnālu:

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

Pēc izmaiņu veikšanas atcerieties restartēt PHP-FPM pakalpojumu, lai izmaiņas stātos spēkā.

systemctl restart php8.5-fpm

Iespējojiet PHP-FPM statusa uzraudzību, lai jebkurā laikā sekotu progresam

Iespējojot PHP-FPM procesu uzraudzību, jūs jebkurā laikā varat skatīt aktīvo procesu skaitu un pieprasījumu gaidīšanas statusu , novēršot servera pārslodzi.

在 php-fpm.conf Pievienots:

pm.status_path = /status

Pēc tam Nginx konfigurācija:

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

Tādā veidā jūs varat http://yourdomain.com/status Pārbaudiet PHP-FPM darbībā!

Optimizējiet PHP-FPM žurnālus, lai ātri novērstu problēmas

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

Šādā veidā ikreiz, kad rodas kļūda 500, varat tieši skatīt žurnālu:

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

Pārbaudiet, vai PHP ziņo par kļūdu, piemēram, out of memory,script execution timeout Pagaidiet.

Regulāri restartējiet PHP-FPM, lai novērstu atmiņas noplūdes

spējīgs tikt garām cron Regulāri restartējiet PHP-FPM, lai novērstu ilgstošu procesu rašanosAtmiņas noplūdes.

crontab -e

Pievienojiet šādu ieplānoto uzdevumu, lai katru dienu plkst. 3:XNUMX automātiski restartētu PHP-FPM:

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

Ko darīt, ja problēma joprojām pastāv? Tālāka optimizācija!

Ja pēc iepriekš minēto optimizāciju veikšanas joprojām laiku pa laikam rodas 500 kļūda , varat turpināt ar šādām optimizācijām:

1. Iespējojiet OPcache, lai uzlabotu PHP izpildes efektivitāti

Ja OPcache vēl nav iespējots, varat to instalēt šādi (izmantojot Ubuntu kā piemēru):

sudo apt install php8.5-opcache -y

Pēc tam rediģējiet php.ini:

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

• opcache.validate_timestamps=0
• Atspējot reāllaika noteikšanuSamaziniet failu sistēmas ievadizvadi un uzlabojiet veiktspēju.

• Tomēr tas nozīmē, ka pēc PHP failu modificēšanas kešatmiņa ir jānotīra manuāli (jārestartē PHP pakalpojums).

Pēc konfigurācijas modificēšanas ir jārestartē PHP pakalpojums, lai izmaiņas stātos spēkā.

sudo systemctl restart php<版本>-fpm

Efekts? PHP lapas izpildes ātrums ir ievērojami uzlabots!

2. Nginx konfigurācijas optimizācija

Pārliecinieties, vai ar Nginx saistītie parametri ir saprātīgi, piemēram, fastcgi_read_timeout Pielāgojiet to atbilstoši, lai izvairītos no tā, ka Nginx pārtrauc PHP skriptus ilga izpildes laika dēļ:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Kopsavilkums: Optimizējiet PHP-FPM, un vietne vairs neavārēs!

Kādas korekcijas esam veikuši pēc šīs optimizācijas?

✅ PHP-FPM procesu pūla optimizēšana, izmantot ondemandUn optimizēt pm.max_children parametrs;
✅ PHP skriptu izpildes laika ierobežošana, lai novērstu ilgstošu CPU noslogojumu;
✅ Iespējot PHP-FPM uzraudzību, apskatīt procesa slodzi reāllaikā;
✅ PHP-FPM žurnālu optimizēšana, ātri novērst 500 kļūdas;
✅ Regulāri restartējiet PHP-FPM, novērstu atmiņas noplūdes;
✅ Iespējot OPcache, uzlabot PHP izpildes efektivitāti;
✅ Nginx konfigurācijas optimizēšana, lai izvairītos no taimauta problēmām.

Pēc šīs optimizācijas PHP-FPM slodze ievērojami samazināsies un mājas lapas darbība būs stabilāka! 🔥

Ej un izmēģini tūlīt! 💪🚀

Ja joprojām vēlaties uzzināt vairāk par PHP-FPM veidņu pielāgošanu, izmantojot HestiaCP, tad šis raksts sniegs jums dziļāku izpratni:

👉 HestiaCP pielāgota PHP-FPM veidne: PHP 8.5 veiktspējas optimizācijas noslēpumi ▼

🔗HestiaCP pielāgota PHP-FPM veidne: PHP 8.5 veiktspējas optimizācijas noslēpumi

Šajā saturā jūs redzēsiet:

• Augstas vienlaicīguma optimizācijas metodes: kā uzlabot reakcijas ātrumu, izmantojot saprātīgu procesa konfigurāciju.
• Drošības izolācijas risinājums: Izvairieties no piekļuves riskiem no dažādām vietnēm un nodrošiniet konta stabilitāti.
• Žurnāli un uzraudzība: Izmantojiet lēnus žurnālus, lai atrastu vājās vietas un nepārtraukti optimizētu vietnes veiktspēju.