Onko HestiaCP PHP-FPM raskaan kuormituksen alla? Dynaaminen verkkosivu 500 virhe? Tämä optimointi astuu voimaan välittömästi!

Oletko koskaan törmännyt tällaiseen tilanteeseen? Verkkosivustosi hidastuu yhtäkkiä tai antaa jopa 500-virheen. PHP-FPM:n uudelleenkäynnistäminen palauttaa sen normaaliksi , mutta ongelma ilmaantuu uudelleen jonkin ajan kuluttua? Se on uskomattoman turhauttavaa!

Miksi näin tapahtuu? Itse asiassa tämän aiheuttaa yleensä virheellinen PHP-FPM-prosessipoolin konfigurointi tai riittämättömät palvelinresurssit . Tänään optimoimme PHP-FPM:n perusteellisesti HestiaCP:n avulla varmistaaksemme verkkosivustosi vankan vakauden!

Ydinsyy, miksi PHP-FPM on ylikuormitettu

PHP-FPM on PHP:n prosessinhallintaohjelma , joka vastaa dynaamisten pyyntöjen käsittelystä. Väärä kokoonpano voi johtaa seuraaviin ongelmiin:

• Palvelinresurssit ovat lopussa, mikä aiheuttaa sen, että PHP-FPM ei pysty vastaamaan uusiin pyyntöihin ajoissa;
• Liian vähän prosesseja, kun liikenne äkillisesti lisääntyy, sitä ei voida käsitellä ajoissa;
• Prosessin käyttö on liian korkea, jolloin suorittimen kuormitus räjähtää.

Mistä tietää, onko PHP-FPM ylikuormitettu?

voi käyttää top 或 htop Komento näyttää suorittimen ja muistin käyttö:

top -c

Jos näet seuraavankaltaisia ​​prosessitietoja, se tarkoittaa, että PHP-FPM toimii suurella kuormituksella:

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

Näetkö näiden prosessien käyttävän yli 70 % suorittimen tehosta? Jos näin tapahtuu usein, PHP-FPM:ssäsi on ehdottomasti jotain vikaa!

Joten kuinka voimme optimoida PHP-FPM-kokoonpanon niin, että palvelin ei enää ole ylikuormitettu?

PHP-FPM prosessipoolin optimointi (ydinparametrien säätö)

Ensin, avaa php-fpm Asetustiedostot:

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

• *Vaihda PHP-versioosi, kuten PHP8.5, ja muuta se tähän:/etc/php/8.3/fpm/pool.d/www.conf

HestiaCP:n asettaman PHP-version kysely

v-list-web-domain user domain.com

Esimerkiksi:

v-list-web-domain abc chenweiliang.com

Tulosteessa näet jotain seuraavanlaista:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

Tämä osoittaa, että verkkosivusto käyttää PHP 8.5:tä.

Katsotaanpa PHP-FPM-konfiguraatiotasi:

[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

Voit nähdä, että sinun pm Käytetty on ondemand,Vaikka se voi vähentää resurssien käyttöä lepotilan aikana, liikenteen äkillisesti lisääntyessä prosessi ei ehkä pysty vastaamaan ajoissa., jolloin tuloksena on 500 virhe.

www.conf: Järjestelmän sisäänrakennettu "universaali resurssipooli"

PHP-FPM:n asentamisen jälkeen järjestelmä tarjoaa sinulle automaattisesti... www.conf tiedosto.
SenPaikannusSe on hyvin yksinkertaista – se on vain oletusarvoinen prosessipooli, joka toimii suoraan pakkauksesta, yleensä liitettynä... www-data Käyttäjän lataus.

Tämän tyyppinen pooli sopii erityisesti yhden sijainnin ympäristöihin: kokoonpano on kevyt ja parametrit ovat kaikki yleisiä malleja, kuten:

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

Jos isännöit vain yhtä sivustoa, voit käyttää sitä suoraan ja luotettavasti ilman ylimääräistä vaivaa.

etufo.org.conf: Mukautettu pooli

Kun sinulla on useita sivustoja, et voi pitää kaikkia samassa altaassa.
Tässä vaiheessa HestiaCP luo automaattisesti erillisen poolin jokaiselle sivustolle, esimerkiksi... etufo.org.conf-tiedostoErikoistunut verkkotunnuksiin etufo.org 服务.

Yleinen tapa pelata on:

• Vaihda käyttäjiä ja ryhmiä:user = etufo,group = etufo
• Riippumaton valvonta:listen = /run/php/etufo.sock
• Prosessien määrän säätäminen varmistaa vankan vakauden jopa korkeissa samanaikaisissa prosesseissa.
• Erilliset lokitiedostot selkeyttävät vianmääritystä.

Edut ovat ilmeiset: turvallinen eristys . Vaikka yksi sivusto vaarantuisi, muut pysyvät ennallaan.

dummy.conf: dummy-tiedosto

nukke.conf Nämä ovat yleensä järjestelmän tarjoamia esimerkkejä tai malleja.
Se ei oikeastaan ​​toimi, ellet muokkaa ja ota sitä käyttöön manuaalisesti.
Sen merkitys on enemmän kuin "käyttöohje", joka kertoo, miten uusi allaskonfiguraatio kirjoitetaan.

Miksi allas pitäisi jakaa?

• 安全 性Käytä eri käyttäjiä eri sivustoilla välttääksesi ristiriitaiset käyttöoikeudet.
• 性能优化Prosessien määrää voidaan säätää erikseen kullekin poolille, mikä mahdollistaa joustavat muutokset liikenteen kysynnän perusteella.
• EristäytyminenLokit, virheet ja kuunteluosoitteet ovat kaikki erillään, mikä helpottaa vianmääritystä.

Esimerkiksi vaikka www.conf kaatuisi, etufo.org.conf toimii silti normaalisti eikä kaada koko palvelinta.

实际场景

• Yhden sivuston palvelinwww.conf riittää.
• MonisivustopalvelinJokaisella sivustolla on oma itsenäinen .conf-tiedostonsa, kuten etufo.org.conf.
• nukke.confVain viitteeksi, ei suositella.

Konfiguraation vertailu

www.conf (oletuspooli)

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

etufo.org.conf (Mukautettu pooli)

[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

Tärkeimmät erot ovat: käyttäjän identiteetti, kuunteluosoite ja prosessien määrä.

1. Säädä PHP-FPM-prosessipooliparametreja

Jos kokoonpano käyttää dynamicTämä on menetelmä, jolla voidaan käynnistää joitakin työprosesseja etukäteen ja säätää niitä dynaamisesti pyyntöjen määrän mukaan, mikä voi reagoida nopeammin, kun pyyntöjen määrä äkillisesti kasvaa.

Verkkosivustoille, joilla on tietty määrä liikennettä, on suositeltavaa käyttää pm = dynamicKoska se pystyy ylläpitämään tietyn määrän käyttämättömiä prosesseja ja välttämään 500 virhettä suuren samanaikaisuuden aikana.

Sitä suositellaan käytettäväksi vain silloin, kun käyttöoikeusmäärä on erittäin pieni ja muistiresurssit ovat tiukat. pm = ondemand Resurssien säästämiseksi.

Ehdotettu vaihtamista dynamicja optimoida pm.max_children Ja muut parametrit:

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

Miksi haluat muuttaa sen näin?

• pm = dynamic: Kohdista prosesseja joustavammin välttääksesi pyyntöjen odottamisen, joka voi aiheutua ondemandista;
• pm.max_children = 16: Estä 500 virheet, jotka johtuvat liian harvoista prosesseista;
• pm.start_servers = 5: Vältä hidasta prosessin käynnistystä;
• pm.max_requests = 3000:Muistivuotojen estäminen, kierrätä prosessi säännöllisesti.

2. Rajoita PHP-komentosarjojen suoritusaikaa estääksesi pitkäaikaisen käytön

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

Tämä estää tiettyjä PHP-skriptejä, jotka kuluttavat liikaa prosessoritehoa, kaatamasta palvelinta.

Käynnistä PHP-prosessi uudelleen tallennuksen jälkeen:

sudo systemctl restart php8.3-fpm

Optimoi PHP-FPM VPS-kokoonpanon perusteella

VPS-konfiguraatioesimerkki:

• Kuvaus: VPS 3 NVMe
• Levytila: 300 Gt
• Suorittimen ytimet: 8
• RAM: 24 GB

VPS-kokoonpanosi ( 8 CPU-ydintä, 24 Gt RAM-muistia ) perusteella palvelinresurssisi ovat enemmän kuin riittävät. PHP-FPM:lle 24 Gt RAM-muistia mahdollistaa erittäin suuren määrän samanaikaisten prosessien konfiguroinnin.

Tuotantoympäristössä varaamme tyypillisesti riittävästi muistia (esimerkiksi 8–12 Gt) itse järjestelmälle, Apachen tietokannoille (kuten MySQL /MariaDB) ja välimuisteille (kuten Redis / Memcached ), jolloin loput 12–16 Gt muistia varataan kokonaan PHP-FPM:lle.

Keskimääräisen 40–60 Mt:n muistinkäytön perusteella PHP-prosessia kohden 1 Gt muistia riittää noin 16–25 prosessin suorittamiseen.

Seuraava on räätälöity sinulle samanaikaista ja tehokasta FPM-kokoonpanoa , joka voi parantaa huomattavasti WordPressin kapasiteettia ja estää sen kaatumisen äkillisten liikennepiikkien vuoksi:

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

💡 Miksi tämä kokoonpano?

1. pm.max_children = 300Tämä on ydintoimintojen optimointi. Aiempi 50 prosessin kokoonpanosi oli liian konservatiivinen 24 Gt:n muistille. Äkillisten liikennepiikkien (tai taustalla olevien bottien) yhteydessä 50 prosessia ylikuormittuu välittömästi, mikä aiheuttaa yhteysaikakatkoksia. Arvon nostaminen 300:aan voi parantaa palvelimesi samanaikaisen käsittelyn kapasiteettia moninkertaisesti.
2. pm.start_servers / `min_spare_serversKoska sinulla on 8 suorittimen ydintä, voit aluksi ja normaalisti säilyttää enemmän käyttämättömiä prosesseja, mikä antaa sinulle mahdollisuuden hyödyntää moniydinetua ja avata uusia pyyntöjä välittömästi odottamatta prosessin luomista.
3. pm.max_requests = 1000Kasvata arvosta 500 arvoon 1000. Muistisi on suuri, eikä prosesseja tarvitse käynnistää uudelleen usein. Arvon nostaminen arvoon 1000 voi vähentää prosessien usein tapahtuvan tuhoamisen ja luomisen aiheuttamaa suorittimen kulutusta.

Katso hidas loki:

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

Muutosten tekemisen jälkeen muista käynnistää PHP-FPM-palvelu uudelleen, jotta muutokset tulevat voimaan.

systemctl restart php8.5-fpm

Ota PHP-FPM-tilan seuranta käyttöön, jotta voit seurata edistymistä milloin tahansa

PHP-FPM-prosessien valvonnan käyttöönotto antaa sinulle mahdollisuuden tarkastella aktiivisten prosessien määrää ja pyyntöjen odottamistilaa milloin tahansa , mikä estää palvelimen ylikuormituksen.

在 php-fpm.conf Lisätty:

pm.status_path = /status

Sitten Nginx-kokoonpano:

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ällä tavalla voit http://yourdomain.com/status Katso PHP-FPM toiminnassa!

Optimoi PHP-FPM-lokit ongelmien nopeaan vianmääritykseen

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

Tällä tavalla voit tarkastella lokia suoraan aina 500-virheen sattuessa:

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

Katso, raportoiko PHP virheestä, esim out of memory,script execution timeout 等.

Käynnistä PHP-FPM säännöllisesti uudelleen muistivuotojen estämiseksi

pystyy ohittamaan cron Käynnistä PHP-FPM uudelleen säännöllisesti estääksesi pitkäaikaisia ​​prosesseja aiheuttamastaMuistivuotoja.

crontab -e

Lisää seuraava ajoitettu tehtävä käynnistääksesi PHP-FPM:n automaattisesti uudelleen joka päivä klo 3:XNUMX:

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

Entä jos ongelma jatkuu? Lisää optimointia!

Jos kohtaat edelleen satunnaisesti 500-virheen yllä olevien optimointien jälkeen , voit jatkaa seuraavilla optimoinneilla:

1. Ota OPcache käyttöön parantaaksesi PHP:n suoritustehokkuutta

Jos OPcache ei ole vielä käytössä, voit asentaa sen seuraavasti (käyttäen Ubuntua esimerkkinä):

sudo apt install php8.5-opcache -y

Muokkaa sitten php.ini:

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

• opcache.validate_timestamps=0
• Poista reaaliaikainen tunnistus käytöstäVähennä tiedostojärjestelmän I/O-arvoja ja paranna suorituskykyä.

• Tämä tarkoittaa kuitenkin, että sinun on tyhjennettävä välimuisti manuaalisesti (käynnistettävä PHP-palvelu uudelleen) PHP-tiedostojen muokkaamisen jälkeen.

Kun olet muokannut asetuksia, sinun on käynnistettävä PHP-palvelu uudelleen, jotta muutokset tulevat voimaan.

sudo systemctl restart php<版本>-fpm

Vaikutus? PHP-sivun suoritusnopeus on parantunut huomattavasti!

2. Nginx-kokoonpanon optimointi

Varmista, että Nginxiin liittyvät parametrit ovat kohtuullisia, kuten fastcgi_read_timeout Säädä se asianmukaisesti, jotta Nginx ei lopeta PHP-skriptejä pitkän suoritusajan vuoksi:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Yhteenveto: Optimoi PHP-FPM, niin verkkosivusto ei enää kaadu!

Mitä muutoksia olemme tehneet tämän optimoinnin jälkeen?

✅ PHP-FPM-prosessipoolin optimointi,käyttää ondemandJa optimoida pm.max_children parametri;
✅ PHP-skriptien suoritusajan rajoittaminen, estääksesi pitkäaikaisen suorittimen käytön;
✅ Ota PHP-FPM-valvonta käyttöön, tarkastella prosessin kuormitusta reaaliajassa;
✅ PHP-FPM-lokien optimointi, vianmääritys nopeasti 500 virhettä;
✅ Käynnistä PHP-FPM säännöllisesti, estää muistivuotoja;
✅ Ota OPcache käyttöön, parantaa PHP:n suoritustehokkuutta;
✅ Nginx-kokoonpanon optimointi, välttääksesi aikakatkaisuongelmia.

Tämän optimoinnin jälkeen PHP-FPM-kuorma vähenee huomattavasti ja verkkosivuston toiminta on vakaampaa! 🔥

Mene kokeilemaan nyt! 💪🚀

Jos haluat edelleen oppia lisää PHP-FPM-mallien mukauttamisesta HestiaCP:n avulla, tämä artikkeli antaa sinulle syvemmän ymmärryksen:

👉 HestiaCP:n mukautettu PHP-FPM-malli: PHP 8.5:n suorituskyvyn optimoinnin salaisuudet ▼

🔗HestiaCP:n mukautettu PHP-FPM-malli: PHP 8.5:n suorituskyvyn optimoinnin salaisuudet

Tässä sisällössä näet:

• Korkean samanaikaisuuden optimointitekniikat: Kuinka parantaa vasteaikaa kohtuullisen prosessikonfiguraation avulla.
• Turvallisuuden eristäminen -ratkaisu: Vältä sivustojen välisen käyttöoikeuden riskit ja varmista tilin vakaus.
• Lokit ja valvonta: Käytä hitaita lokeja pullonkaulojen paikantamiseen ja verkkosivuston suorituskyvyn jatkuvaan optimointiin.