Elke maandagochtend crasht een e-commercesite. Het team stelt het VPS-plan op. De volgende maandag hetzelfde symptoom: witte pagina's, Nginx retourneert 502 Bad Gateway. Het echte probleem was niet de CPU; het was PHP-FPM die tegelijkertijd zijn werkers en RAM had uitgeput. FPM-balansen responscapaciteit en geheugenplafond instellen. Slecht gekalibreerd wordt de server een gok: bezoekers wachten, of de kernel stopt processen.
PHP-FPM beheert een pool van PHP-processen. Elke dynamische aanvraag verbruikt een werker. Als alle 20 werknemers bezig zijn, wacht het 21e verzoek in een wachtrij: de TTFB ontploft. Als je 200 op 4 GB RAM draait, treedt de OOM-killer in werking.
Lees de huidige status voordat u iets aanraakt
Allereerst pm.max_children = 50 gekopieerd van een forum:
# FPM- en RAM-processen (voorbeeldpool www)
ps --no-headers -o rss,cmd -C php-fpm8.2 | awk '{sum+=$1} END {print sum/1024 "Totaal MB"}'
Zoek ook:
listen.queueinphp-fpm status— lopende verzoeken.- 502/504 gecorreleerd met pieken in Nginx-logboeken.
slowlog— scripts die werknemers lange tijd vasthouden.
| Signaal | Interpretatie |
|---|---|
| Staart > 0 normaal | Niet genoeg werkers of scripts te traag |
| RAM-swap gebruikt | Te veel werkers of PHP-geheugenlek |
| Werknemers inactief = max. permanent | Ondermaats zwembad |
| Werknemers inactief = 0, RAM OK | Trage scripts, geen te kleine pool |
Bereken pm.max_children zonder magische formule
De basisformule:
max_children ≈ (RAM toegewezen aan PHP-pool) / (gemiddeld RAM per werknemer onder belasting)
Meet het RAM-geheugen per werknemer met realistisch verkeer (geen lege startpagina). Zware WordPress draait vaak tussen de 60 en 120 MB per proces. Laravel of Magento gaan hoger.
Op een 8 GB VPS waar PHP 4 GB kan gebruiken:
- Gemiddelde werknemer: 100 MB → theoretisch max. 40.
- Behoud een marge van 20–30% voor OS, MySQL, Redis → streef naar 28–32, niet naar 40.
De pm-modi:
| Mode | Gedrag | Gebruiksscenario's |
|---|---|---|
| dynamisch | Spawn tussen min en max, afhankelijk van de belasting | Variabele sites, goed compromis |
| statisch | Altijd maximale actieve werknemers | Stabiel opladen, minimale latentie |
| op aanvraag | Op aanvraag gemaakt, time-out bij inactiviteit | Zeer beperkt RAM-geheugen, accepteert koude start |
slowlog, request_terminate_timeout en veelvoorkomende fouten
request_slowlog_timeout (bijv. 5 s) + slowlog = lijst met scripts die werkers monopoliseren. Corrigeer de code voordat u processen toevoegt.
request_terminate_timeout onderbreekt een oneindig script - nuttig, maar kan legitieme importbewerkingen afkappen als deze slecht is ingesteld.
Klassieke fouten:
- Kopieer een productiepool naar een gedeelde pool — andere limieten, account opgeschort.
- MySQL negeren — 50 werkers × langzame query's = 50 verzadigde DB-verbindingen.
- OPcache uitgeschakeld of onjuist formaat — elke worker laadt de bytecode opnieuw, RAM opgeblazen (zie OPcache).
- hoge max_children + geen paginacache — WordPress herberekent alles bij elke hit.
De top: meer werknemers verbergt een trage applicatie
Dit is het punt dat de “onbeperkte” aanbiedingen ontgaan: onbeperkt aan de bezoekerskant betekent niet onbeperkt aan de PHP-proceskant.
Beslis en ga vooruit zonder blinde vlek
- Meet RAM/werker en staartlengte onder werkelijke belasting.
- Bereken max_children met marge; kies dynamisch of statisch.
- Schakel slowlog in, repareer de vermelde scripts.
- Hertest belasting en TTFB; vergelijk alleen accommodaties als het zwembad gezond is.
Voor een upstream-diagnose leest u Hoge TTFB. Om een VPS met volledige pooltoegang te filteren, bladert u door de overzicht of de vergelijker.
Veelgestelde vragen
Hoe pm.max_children berekenen?
RAM beschikbaar voor PHP gedeeld door het gemiddelde verbruik van een werknemer onder belasting, met een marge van 20-30%.
dynamisch, on-demand of statisch: welke te kiezen?
dynamisch voor variabel verkeer; statisch voor stabiele belasting; ondemand als het RAM-geheugen zeer beperkt is en u akkoord gaat met de opstartlatentie.
Wat te doen als de slowlog de schijf vult?
Realistische drempel, scriptcorrectie, niet alleen logrotatie.
Kan de host mijn FPM-wijzigingen blokkeren?
Ja, gedeeld; op VPS beheert u de pool - controleer contractuele limieten.
Voordat u het aantal werknemers vergroot, vraagt u zich af: hoeveel MB per verzoek en hoeveel seconden per script? Als u het niet weet, is FPM-afstemming een loterij en geen uitbuiting.