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?Reteja aliro subite malrapidiĝis, aŭ eĉ rezultigis 500-eraron Post rekomenco de PHP-FPM, ĝi revenis al normalo., sed la problemo reaperas post iom da tempo? Ĉi tio estas tiel frustra!

Kial tio okazas?Fakte, ĉi tio estas kutimeLa procezgrupo de PHP-FPM ne estas agordita ĝuste, aŭ la servilaj rimedoj estas nesufiĉaj.kaŭzita de. Hodiaŭ ni plene optimumigos HestiaCP PHP-FPM sub la kapuĉo faras la retejon tiel stabila kiel roko!

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

PHP-FPM estas aProceza Administranto, kiu respondecas pri pritraktado de dinamikaj petoj. Se la agordo ne estas racia, ĝi 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

Vidu kiel ĉi tiuj procezoj okupas pli ol 70% de la CPU? Se ĉi tio okazas ofte, via PHP-FPM Devas esti problemo!

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.3, 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.3

Ĉi tio signifas, ke la retejo uzas PHP 8.3.

Ni rigardu vian PHP-FPM-agordon:

[chenweiliang.com]
listen = /run/php/php8.3-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.

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 ondemand, 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 进程最大内存占用

Ĉi tio povas malhelpi iujnPHP-skriptoj, kiuj uzas tro da CPU, povas detrui vian servilon.

Post konservado, rekomencu la PHP-procezon:

sudo systemctl restart php8.3-fpm

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

Ebligu PHP-FPM-procezmonitoradon kaj rigardu ĝin iam ajnNuna nombro da aktivaj procezoj kaj peta atendanta stato, por eviti servilon troŝarĝon.

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.3-fpm restart

Kio se la problemo daŭras? Plia optimumigo!

Se vi ankoraŭ sekvas la supre optimumigoFoje okazas 500 eraroj, vi povas daŭrigi kun la sekvaj 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.3-opcache -y

Poste redakti php.ini:

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

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! 💪🚀