Artikel Directory
Heb je dit wel eens meegemaakt? Je website wordt ineens traag of geeft zelfs een 500-foutmelding. PHP-FPM opnieuw opstarten lost het probleem op , maar na een tijdje duikt het weer op? Dat is ontzettend frustrerend!
Waarom gebeurt dit? Meestal wordt dit veroorzaakt door een onjuiste configuratie van de PHP-FPM-procespool of onvoldoende serverbronnen . Vandaag optimaliseren we PHP-FPM grondig onder HestiaCP om de ijzersterke stabiliteit van uw website te garanderen!
De belangrijkste reden waarom PHP-FPM overbelast is
PHP-FPM is de procesmanager voor PHP , verantwoordelijk voor het afhandelen van dynamische verzoeken. Een onjuiste configuratie kan leiden tot:
- Serverbronnen zijn uitgeputwaardoor PHP-FPM niet tijdig op nieuwe verzoeken kan reageren;
- Te weinig processen, wanneer het verkeer plotseling toeneemt, kan dit niet op tijd worden verwerkt;
- Procesgebruik is te hoogwaardoor de CPU-belasting explodeert.

Hoe weet ik of PHP-FPM overbelast is?
kan gebruiken top 或 htop Opdracht om CPU- en geheugengebruik te bekijken:
top -c
Als u procesinformatie ziet die lijkt op de volgende, betekent dit dat PHP-FPM onder hoge belasting draait:
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
Gebruiken deze processen meer dan 70% van de CPU? Als dit vaak voorkomt, is er zeker iets mis met uw PHP-FPM!
Hoe kunnen we de PHP-FPM-configuratie optimaliseren, zodat de server niet langer overbelast raakt?
PHP-FPM-procespooloptimalisatie (aanpassing van kernparameters)
Open eerst php-fpm Beschrijving:
sudo nano /etc/php/*/fpm/pool.d/www.conf- *Ga naar uw PHP-versie, bijvoorbeeld PHP8.5, en wijzig deze naar het volgende:
/etc/php/8.3/fpm/pool.d/www.conf
Vraag de PHP-versie op die door HestiaCP is ingesteld
v-list-web-domain user domain.com
Bijvoorbeeld:
v-list-web-domain abc chenweiliang.com
In de uitvoer ziet u zoiets als:
PHP SUPPORT yes
PHP MODE php-fpm
PHP VERSION 8.5 Dit geeft aan dat de website PHP 8.5 gebruikt.
Laten we eens kijken naar uw PHP-FPM-configuratie:
[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
Je kunt zien dat je pm Degene die gebruikt wordt is ondemand,Hoewel het proces het resourcegebruik tijdens inactieve tijd kan verminderen, kan het proces mogelijk niet op tijd reageren wanneer het verkeer plotseling toeneemt., wat resulteerde in een 500-fout.
www.conf: De ingebouwde "universele resourcepool" van het systeem
Na de installatie van PHP-FPM zal het systeem u automatisch voorzien van een... www.conf het dossier.
haarPositioneringHet is heel eenvoudig: het is gewoon een standaard procespool die direct werkt, meestal gekoppeld aan... www-data Gebruikersdownload.
Dit type pool is bijzonder geschikt voor omgevingen met één locatie: de configuratie is eenvoudig en de parameters zijn allemaal generieke sjablonen, zoals:
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm.max_children = 5
Als je maar één website host, kun je die direct en betrouwbaar gebruiken zonder extra gedoe.
etufo.org.conf: Aangepaste pool
Als je meerdere websites beheert, kun je niet iedereen in dezelfde pool onderbrengen.
Op dit punt zal HestiaCP automatisch een aparte pool voor elke site aanmaken, bijvoorbeeld... etufo.org.confGespecialiseerd in domeinnamen etufo.org 服务.
De gebruikelijke manier van spelen is:
- Gebruikers en groepen wijzigen:
user = etufo,group = etufo - Onafhankelijke monitoring:
listen = /run/php/etufo.sock - Door het aantal processen aan te passen, wordt een ijzersterke stabiliteit gegarandeerd, zelfs bij een hoge gelijktijdigheid.
- Aparte logbestanden maken het oplossen van problemen overzichtelijker.
De voordelen zijn duidelijk: veilige isolatie . Zelfs als één site wordt gehackt, blijven de andere onaangetast.
dummy.conf: dummybestand
dummy.conf Dit zijn doorgaans voorbeelden of sjablonen die door het systeem worden aangeboden.
Het programma zal pas werken als je het handmatig aanpast en inschakelt.
De betekenis ervan is eerder te vergelijken met een "handleiding", waarin wordt uitgelegd hoe je een nieuwe zwembadconfiguratie moet maken.
Waarom het zwembad opsplitsen?
- 安全 性Gebruik verschillende gebruikers voor verschillende sites om conflicterende machtigingen te voorkomen.
- Ik denk dat dit het geval isHet aantal processen kan voor elke pool afzonderlijk worden aangepast, waardoor flexibele aanpassingen mogelijk zijn op basis van de verkeersvraag.
- IsolatieLogbestanden, foutmeldingen en luisteradressen zijn allemaal gescheiden, wat het oplossen van problemen vereenvoudigt.
Als bijvoorbeeld www.conf vastloopt, blijft etufo.org.conf gewoon functioneren en zal de server niet volledig uitvallen.
实际场景
- Server voor één locatiewww.conf is voldoende.
- Multisite-serverElke site heeft zijn eigen onafhankelijke .conf-bestand, zoals etufo.org.conf.
- dummy.confUitsluitend ter referentie, niet aanbevolen.
Configuratievergelijking
www.conf (standaardpool)
[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 5
etufo.org.conf (Aangepaste pool)
[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
De belangrijkste verschillen zijn: gebruikersidentiteit, luisteradres en aantal processen.
1. PHP-FPM-procespoolparameters aanpassen
Als de configuratie gebruik maakt van dynamicDit is een methode om bepaalde werkprocessen alvast op te starten en dynamisch aan te passen op basis van het aanvraagvolume. Zo kan er sneller worden gereageerd als het aanvraagvolume plotseling toeneemt.
Voor websites met een bepaalde hoeveelheid verkeer wordt het aanbevolen om pm = dynamicOmdat het een bepaald aantal inactieve processen in stand kan houden en 500 fouten kan vermijden bij hoge gelijktijdigheid.
Het wordt aanbevolen om dit alleen te gebruiken wanneer het toegangsvolume extreem laag is en de geheugenbronnen beperkt zijn. pm = ondemand Om hulpbronnen te besparen.
Voorgesteld om te veranderen naar dynamicen optimaliseren pm.max_children En andere 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 后自动退出
Waarom wil je het zo veranderen?
pm = dynamic: Processen flexibeler toewijzen om wachttijden voor aanvragen te voorkomen die kunnen ontstaan door on-demand;pm.max_children = 16: Voorkom 500 fouten veroorzaakt door te weinig processen;pm.start_servers = 5: Voorkom een langzame opstart van het proces;pm.max_requests = 3000:Voorkomen van geheugenlekken, herhaal het proces regelmatig.
2. Beperk de uitvoeringstijd van PHP-scripts om langdurige bezetting te voorkomen
request_terminate_timeout = 30s ; 超过 30s 的 PHP 脚本自动终止
php_admin_value[memory_limit] = 128M ; 限制 PHP 进程最大内存占用
Dit voorkomt dat bepaalde PHP-scripts die buitensporig veel CPU-kracht verbruiken, de server laten crashen.
Start het PHP-proces opnieuw nadat u het hebt opgeslagen:
sudo systemctl restart php8.3-fpmOptimaliseer PHP-FPM op basis van de VPS-configuratie.
Voorbeeld van een VPS-configuratie:
- Beschrijving: VPS 3 NVMe
- Schijfruimte: 300 GB
- CPU-kernen: 8
- RAM: 24 GB
Op basis van uw VPS-configuratie ( 8 CPU-cores, 24 GB RAM ) zijn uw serverbronnen meer dan voldoende. Voor PHP-FPM kunt u met 24 GB RAM een zeer groot aantal gelijktijdige processen configureren.
In een productieomgeving reserveren we doorgaans voldoende geheugen (bijvoorbeeld 8-12 GB) voor het systeem zelf, Apache-databases (zoals MySQL /MariaDB) en caches (zoals Redis / Memcached ), waarbij de resterende 12-16 GB geheugen volledig wordt toegewezen aan PHP-FPM.
Uitgaande van een gemiddeld geheugengebruik van 40-60 MB per PHP-proces , kan 1 GB geheugen ongeveer 16-25 processen uitvoeren.
Hieronder vindt u een FPM-configuratie met hoge gelijktijdigheid en prestaties, speciaal voor u samengesteld . Deze configuratie kan de capaciteit van WordPress aanzienlijk verbeteren en voorkomen dat het vastloopt door plotselinge verkeerspieken:
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 deze configuratie?
pm.max_children = 300Dit is een belangrijke optimalisatie. Uw vorige configuratie van 50 processen was te beperkt voor 24 GB geheugen. Bij plotselinge pieken in het verkeer (of bots die de achtergrond overspoelen) zouden 50 processen direct overbelast raken, wat verbindingsproblemen zou veroorzaken. Door dit aantal te verhogen naar 300 kan de gelijktijdige verwerkingscapaciteit van uw server aanzienlijk verbeteren.pm.start_servers/ `min_spare_serversDoordat je 8 CPU-cores hebt, kun je in eerste instantie en normaal gesproken meer inactieve processen behouden. Hierdoor kun je profiteren van het voordeel van meerdere cores, zodat nieuwe verzoeken direct kunnen worden geopend zonder te hoeven wachten op de aanmaak van processen.pm.max_requests = 1000Verhoog van 500 naar 1000. Je geheugen is groot en processen hoeven niet vaak opnieuw te worden opgestart. Door te verhogen naar 1000 kan het CPU-gebruik dat wordt veroorzaakt door het frequent beëindigen en aanmaken van processen worden verminderd.
Bekijk het logboek met vertragingen:
tail -f /var/log/php8.5-fpm.log.slowtail -f /var/log/php8.4-fpm.log.slow
Vergeet na het aanbrengen van de wijzigingen niet de PHP-FPM-service opnieuw te starten, zodat de wijzigingen van kracht worden.
systemctl restart php8.5-fpmSchakel PHP-FPM-statusbewaking in om op elk moment de voortgang bij te houden
Door PHP-FPM-procesmonitoring in te schakelen, kunt u op elk moment het aantal actieve processen en de status van wachtende aanvragen bekijken , waardoor serveroverbelasting wordt voorkomen.
在 php-fpm.conf Toegevoegd in:
pm.status_path = /status
Vervolgens de Nginx-configuratie:
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 deze manier kunt u http://yourdomain.com/status Bekijk PHP-FPM in actie!
Optimaliseer PHP-FPM-logs om problemen snel op te lossen
在 php-fpm.conf Tijdschrift:
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 deze manier kunt u het logboek direct bekijken wanneer er een 500-fout optreedt:
tail -f /var/log/php-fpm/error.log
Kijk of PHP een fout meldt, zoals out of memory,script execution timeout 等.
Start PHP-FPM regelmatig opnieuw op om geheugenlekken te voorkomen
kunnen passeren cron Start PHP-FPM regelmatig opnieuw op om te voorkomen dat langlopende processen problemen veroorzaken.Geheugenlekken.
crontab -e
Voeg de volgende geplande taak toe om PHP-FPM elke dag om 3 uur automatisch opnieuw te starten:
0 3 * * * /usr/sbin/service php8.5-fpm restart
Wat als het probleem zich blijft voordoen? Verder optimaliseren!
Als je na het toepassen van bovenstaande optimalisaties nog steeds af en toe een 500-foutmelding krijgt , kun je de volgende optimalisaties uitvoeren:
1. Schakel OPcache in om de PHP-uitvoeringsefficiëntie te verbeteren
Als OPcache nog niet is ingeschakeld, kunt u het als volgt installeren (met Ubuntu als voorbeeld):
sudo apt install php8.5-opcache -y
Bewerk dan php.ini:
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.validate_timestamps=0
- opcache.validate_timestamps=0
- Schakel realtime detectie uitVerminder de I/O van het bestandssysteem en verbeter de prestaties.
Dit betekent echter dat u de cache handmatig moet wissen (de PHP-service opnieuw moet starten) nadat u PHP-bestanden hebt gewijzigd.
Na het wijzigen van de configuratie moet u de PHP-service opnieuw starten om de wijzigingen door te voeren.
sudo systemctl restart php<版本>-fpmEffect? De uitvoeringssnelheid van PHP-pagina's is aanzienlijk verbeterd!
2. Nginx-configuratie-optimalisatie
Zorg ervoor dat Nginx-gerelateerde parameters redelijk zijn, zoals fastcgi_read_timeout Pas het op de juiste manier aan om te voorkomen dat PHP-scripts door Nginx worden beëindigd vanwege een lange uitvoeringstijd:
fastcgi_read_timeout 60s;
client_max_body_size 100M;
Samenvatting: Optimaliseer PHP-FPM en de website zal niet langer crashen!
Welke aanpassingen hebben we gedaan na deze optimalisatie?
✅ Optimaliseren van de PHP-FPM-procespool,gebruik ondemandEn optimaliseren pm.max_children parameter;
✅ Beperking van de uitvoeringstijd van PHP-scriptsom langdurige CPU-bezetting te voorkomen;
✅ PHP-FPM-bewaking inschakelen, bekijk de procesbelasting in realtime;
✅ PHP-FPM-logs optimaliseren, snel 500 fouten oplossen;
✅ PHP-FPM regelmatig opnieuw opstarten, geheugenlekken voorkomen;
✅ OPcache inschakelen, verbeter de PHP-uitvoeringsefficiëntie;
✅ Nginx-configuratie optimaliseren, om time-outproblemen te voorkomen.
Na deze optimalisatie zal de PHP-FPM-belasting aanzienlijk worden verminderd en zal de werking van de website stabieler zijn! 🔥
Probeer het nu! 💪🚀
Als je nog steeds meer wilt leren over het aanpassen van PHP-FPM-templates met HestiaCP, dan geeft dit artikel je een dieper inzicht:
👉 HestiaCP Aangepaste PHP-FPM-sjabloon: Geheimen voor prestatieoptimalisatie in PHP 8.5 ▼
In deze inhoud ziet u het volgende:
- Optimalisatietechnieken voor hoge gelijktijdigheid: Hoe de reactiesnelheid te verbeteren door een verstandige procesconfiguratie.
- Beveiligingsisolatieoplossing: Voorkom risico's van toegang vanaf meerdere locaties en waarborg de stabiliteit van uw account.
- Logs en monitoring: Gebruik slow logs om knelpunten te lokaliseren en de websiteprestaties continu te optimaliseren.
Hopelijk is het artikel "HestiaCP PHP-FPM Overload? Dynamische webpagina 500-fout? Deze optimalisatiemethode levert direct resultaat op!" dat gedeeld is op de blog van Chen Weiliang ( https://www.chenweiliang.com/ ) nuttig voor u.
Deel gerust de link naar dit artikel: https://www.chenweiliang.com/cwl-32512.html

