Nginx geeft 'upstream time-out tijdens het lezen van de responsheader van upstream' weer. PHP-FPM geeft luisterwachtrij len 32 aan. Onmiddellijke reflex: verander pm.max_children van 50 naar 150. Het verkeer wordt geabsorbeerd - RAM stijgt naar 98%, de OOM-killer raakt MySQL. Oorzaak nooit aangepakt: een synchrone betalingswebhook van 25 seconden per bestelling.
Verzadigde PHP-FPM presenteert twee ziekten met vergelijkbare symptomen: feitelijk niet genoeg werkers voor een korte CPU-belasting, of werkers geblokkeerd op netwerk-I/O, trage SQL-query, bestandsvergrendeling. Het verwarren van deze twee kost veel RAM - en verbergt het echte knelpunt wekenlang.
Als de slowlog overal dezelfde oproeptracering weergeeft, is het geen FPM-probleem; het is die oproeptrace.
De gouden regel: vierentwintig uur slowlog, daarna pm-instelling – nooit andersom. Het verhogen van max_children zonder het kritieke pad te verkorten betekent het inhuren van kassiers terwijl elke klant nog steeds betaalt met onaangekondigde cheques.
Lees de php-fpm-status en slowlog
Schakel eerst zichtbaarheid in:
pm.status_path = /fpm-status
ping.pad = /fpm-ping
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
Bescherm /fpm-status achter nginx - maak het niet publiekelijk openbaar. Verzadigingssignalen:
actieve processen≈ max permanent;luisterwachtrij> 0;server heeft pm.max_children-logboeken bereikt.
RAM-formule: (max_children × geheugen per kind) + OS + MySQL <totaal RAM — marge minimaal 20%.
Diagnose A versus B: onvoldoende werknemers of blokkeercode
A — onvoldoende werkers: verzoeken van minder dan 200 ms, hoge PHP-processor, lege slowlog of gediversifieerde sporen → verhoog pm.max_children in stappen van tien, waarbij RAM wordt gecontroleerd.
B — code blokkeren: actieve werkers, lage processor, slowlog geconcentreerd op dezelfde regel (curl, PDO, file_get_contents) → in asynchrone wachtrij plaatsen, curl time-out drie tot vijf seconden, correctie van de SQL-index — zie missing MySQL index en PHP profiling.
Breng fastcgi_read_timeout nginx in lijn met de realiteit van de applicatie - een nginx-time-out korter dan de webhook verbergt het probleem in 504 zonder slowlog. Bij gedeeld is een door de host opgelegde proceslimiet een signaal van een VPS-upgrade in plaats van een oneindige afstemming.
Voor N+1 queries, zie MySQL dynamic site — een query-lus kan alle werkers zonder hoge CPU blokkeren.
Tuning pm: dynamisch, on-demand, statisch
| Mode | Wanneer moet u het gebruiken | Risico |
|---|---|---|
| dynamisch | Variabel verkeer, gecontroleerd RAM | Onverwachte pieken als max_children te laag is |
| op aanvraag | Sporadisch verkeer, beperkt RAM | Latentie bij koude start |
| statisch | Platte belasting, voorspelbaar RAM | Afval als er weinig verkeer is |
Begin met pm = dynamic met pm.max_children berekend op basis van de RAM-formule. Test 'ondemand' alleen als de latentie bij koude start acceptabel is voor uw publiek.
De top: geen werknemers meer met blokkeercode
Vergelijk VPS waarbij je PHP-FPM beheert via de overzicht. Op een gedeeld platform valt niet te onderhandelen over het procesplafond: de diagnose blijft hetzelfde, maar de oplossing omvat upgrades of code-optimalisatie.
Beslis en ga vooruit zonder blinde vlek
Voordat u max_children verhoogt:
- Activeer status en slowlog — zonder zichtbaarheid stem je blindelings af.
- Classificeer de verzadiging: hoge processor (A) of drukke werknemers, lage processor (B).
- Corrigeer de code of SQL als de slowlog geconcentreerd is – geen pm-afstemming vóór correctie.
- Pas pm.max_children aan in stappen van tien met gedocumenteerd RAM-budget.
- Lijn fastcgi_read_timeout nginx en applicatietime-outs uit (curl, PDO).
- Laadtest hetzelfde eindpunt na het patchen: de wachtrij moet bij normale belasting op nul blijven staan.
Veelgestelde vragen
Hoe weet ik of PHP-FPM verzadigd is?
luisterwachtrij groter dan nul, max_children-logboeken bereikt, 502/504 nginx-fouten, latentie lineair met verkeer. Schakel pm.status_path in om te observeren vóór de fout, en niet pas erna.
Is het verhogen van max_children voldoende?
Tijdelijk voor diagnose A. Bereken het beschikbare RAM; als de slowlog geconcentreerd is, repareer dan eerst de code; het verdubbelen van werknemers met blokkerende code veroorzaakt een OOM-kill.
Hoe blokkeercode identificeren?
slowlog PHP-FPM en profileringstool. Symptoom: alle werknemers zijn bezig, CPU laag. Overal hetzelfde spoor = geïdentificeerd knelpunt – geen gebrek aan werknemers.
on-demand versus dynamisch?
dynamisch of on-demand voor variabel verkeer; statisch voor vlakke belasting. ondemand bespaart RAM, maar voegt opstartlatentie toe - test in pre-productie.
Verzadigde PHP-FPM duidt op een gebrek aan kassa's of vaste kassamedewerkers. Het verwarren van de twee kost veel RAM.