Ga naar de inhoud 
PHP-FPM Kinderen in WordPress bepalen of aanvragen soepel verlopen of in de wachtrij blijven hangen. Ik zal je laten zien hoe onjuist pm.max_kinderen-waarden blokkeren pagina's, verbruiken RAM en hoe ik schone waarden bereken.
Centrale punten
Voordat ik er dieper op inga, zal ik de belangrijkste boodschappen kort samenvatten:
- pm.max_kinderen bepaalt hoeveel gelijktijdige PHP-verzoeken er worden uitgevoerd.
- Te weinig Kinderen genereren wachtrijen, 502/504 en hoge TTFB.
- Te veel leidt tot RAM knelpunten, swap en OOM kills.
- Formulebeschikbaar PHP RAM / procesgrootte × 0,7-0,8.
- Iteratief Afstemmen met monitoring levert de beste prestaties op de lange termijn.
Waarom onjuiste PHP-FPM-kinderpagina's blokkeren
Elk dynamisch WordPress verzoek heeft zijn eigen Werknemer, en het zijn precies deze processen die de pool regelt via pm.max_children. Als ik de waarde te laag instel, stapelen verzoeken zich op in een wachtrij en de TTFB neemt merkbaar toe. Als ik de waarde te hoog instel, gebruikt elk kindproces extra RAM en schakelt de server over op swap. Alles vertraagt in de swap totdat Apache of Nginx 502/504 rapporteren of de OOM-killer processen beëindigt. Gezonde doorvoer wordt alleen bereikt als het aantal kinderen overeenkomt met het echte RAM-budget en de belasting van het project.
De formule voor pm.max_children in de praktijk
Ik begin met de eenvoudige formule: beschikbaar RAM-geheugen voor PHP gedeeld door de gemiddelde grootte van een kindproces, vermenigvuldigd met een Veiligheidsfactor Ik bepaal het RAM per proces met ps en de RSS kolom; voor typische WordPress stacks is 50-250 MB vaak correct. Op een 4 GB server reserveer ik geheugen voor Linux, database en cache services, waardoor er ongeveer 1,5-2 GB overblijft voor PHP blijven. Als het procesgemiddelde bijvoorbeeld 100 MB is, dan zijn 2.000 / 100 × 0,75 = 15 kinderen. Dit getal dient als uitgangspunt, dat ik verfijn op basis van het belastingsprofiel, caching en plugin-mix.
Beginwaarden voor typische WordPress-instellingen
Voor kleine blogs met 2 GB RAM, 8 kinderen, pm = dynamic en een pm.max_requests van ca. 800. Voor middelgrote projecten met 4 GB RAM stel ik 12 kinderen in, start_servers 4, min_spare_servers 4. Grote shops met 8 GB RAM of meer hebben baat bij 21-40 kinderen; als de belasting permanent hoog is, kan pm = static een constante doorvoer garanderen. Ik controleer dan de verhouding tussen CPU-gebruik, RAM-gebruik en responstijden om fijnafstellingen te maken. Als je dieper wilt graven, kun je achtergrondinformatie vinden op optimale PHP-FPM instellingen.
Processen meten: hoe RAM-vereisten bepalen
Ik bepaal eerst de live grootte van de processen voordat ik waarden instel, omdat kristallen bollen hier niet helpen en geld kosten. Prestaties. De opdracht ps -ylC php-fpm -sort:rss geeft de RSS groottes, die ik over een paar minuten controleer. Processen groeien vaak tijdens updates of cron jobs, daarom neem ik pieken mee in de berekening. Ik gebruik ook htop en free -h om de RAM reserves en de hoeveelheid swap te controleren. Ik gebruik deze gegevens om een betrouwbaar gemiddelde te bepalen en kies een conservatieve veiligheidsfactor.
Belangrijke parameters in een oogopslag
Naast pm.max_children bepalen andere poolopties hoe netjes WordPress verzoeken verwerkt en hoe goed het geheugen vrijmaakt, waardoor de Stabiliteit pm regelt de modus: dynamisch past het aantal processen aan de belasting aan, statisch handhaaft een vast aantal. pm.max_requests voorkomt geheugenophoping door processen na X verzoeken opnieuw te starten. request_terminate_timeout beschermt tegen hang-ups veroorzaakt door defecte of langzame scripts. Met deze set dek ik 90 procent van de echte praktijkgevallen.
| Parameters | Functie | WordPress aanbeveling |
|---|---|---|
| pm | Procesbesturingsmodus | dynamisch voor variabele belasting; statisch voor permanent veel verkeer |
| pm.max_kinderen | Maximum aantal gelijktijdige werknemers | Beschikbaar PHP RAM / procesgrootte × 0,75 |
| pm.max_aanvragen | Recycling van processen | 300-1.000; eerder lager met WooCommerce |
| verzoek_terminate_timeout | Annulering van langlopende verzoeken | 60-120 seconden tegen hangers |
Dynamisch, on-demand of statisch - welke modus is geschikt voor jou?
Ik selecteer de modus die past bij het belastingsprofiel: dynamisch is mijn standaard, omdat het flexibel het aantal actieve processen aanpast en dus RAM bespaart als er weinig gebeurt. statisch Ik gebruik het wanneer de belasting constant is en ik harde toezeggingen nodig heb in termen van latentie en doorvoer - bijvoorbeeld tijdens campagnes of verkoop. ondemand is geschikt voor servers met lange inactieve fasen: Processen worden alleen aangemaakt wanneer dat nodig is en weer beëindigd na inactiviteit. De afweging is koude start; de eerste aanvraag per nieuw proces voelt langzamer aan. Voor ondemand stel ik pm.process_idle_timeout netjes (bijv. 10-20s), met dynamiek houd ik start_servers, min_reserve servers en max_spare_servers smal zodat de pool snel schaalt maar niet „opzwelt“.
Configuratievoorbeeld voor uw pool
Op Debian/Ubuntu staat het poolbestand meestal onder /etc/php/8.x/fpm/pool.d/www.conf, wat me een duidelijke Structuur voor aanpassingen. Ik stel pm in op dynamisch, anker een realistische waarde voor pm.max_children en houd de reserve server strak. Ik stel de recycling in op 500 om lekken en RAM-geheugenuitbreidingen in een vroeg stadium te beperken. Na elke verandering test ik de belasting en sluit ik knelpunten voordat ik de waarden verder verhoog. Voor achtergrondinformatie over limietwaarden, het inzicht op pm.max_children optimaliseren.
pm = dynamisch
pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_aanvragen = 500
verzoek_terminate_timeout = 90s
Meerdere zwembaden, stopcontacten en schone isolatie
Voor meerdere projecten of duidelijk gescheiden rollen (frontend vs. admin/REST) stel ik het volgende in aparte zwembaden met zijn eigen gebruiker en socket. Op deze manier beperkt elke pool zijn eigen kinderen en blokkeert één uitschieter de rest niet. Op een host geef ik de voorkeur aan Unix sockets vergeleken met TCP (listen = /run/php/site.sock) - lagere latency, minder overhead. Ik gebruik TCP tussen Nginx/Apache en PHP-FPM op verschillende hosts/containers. Ik gebruik listen.owner, listen.group en listen.mode consistent zijn en, indien nodig, verhogen listen.backlog zodat korte belastingspieken niet resulteren in verbindingsfouten. Met een speciale beheerderspool kan ik een strakkere verzoek_terminate_timeout aandrijving en pm.max_aanvragen lager zonder de cachingsterke frontend pool te vertragen.
Symptomen herkennen en juist reageren
Als in het foutenlogboek regelmatig „server reached pm.max_children“ staat, beperkt de pool de Parallellisme en ik verhoog het met mate. Als 502/504 tegelijkertijd voorkomen met een hoog swapgebruik, stel ik pm.max_children opnieuw in en verlaag ik pm.max_requests. Als de CPU toeneemt met een laag RAM-gebruik, dan blokkeren query's of PHP-logica meestal; ik optimaliseer de database en caching. Als verzoeken vastlopen, helpt een striktere request_terminate_timeout en logboekanalyse met tijdstempels. Ik controleer opvallende pieken met cronjobs, zoekindices en adminacties.
FPM-status en slowlog: precieze diagnose
Ik activeer de Status per pool (pm.status_path) en lees belangrijke cijfers zoals actieve processen, max. bereikte kinderen, luisterwachtrij en max luisterwachtrij uit. Een permanent groeiende lijstwachtrij laat duidelijk zien: te weinig kinderen of blokkerende backends. Ik heb ook verzoek_slowlog_timeout (bijv. 3-5s) en een slowlog-pad. Zo zie ik stack traces van aanvragen die treuzelen - vaak externe HTTP-aanroepen, complexe WooCommerce query's of manipulaties van afbeeldingen. Met catch_workers_output waarschuwingen van de workers worden verzameld in de logs. Op basis van deze gegevens beslis ik of meer parallellisme helpt of dat ik knelpunten in de code/DB moet oplossen.
Controle: 3-5 dagen schone evaluatie
Na het afstemmen observeer ik belastingspieken over meerdere dagen, omdat kortstondige schommelingen misleiden. Ik log RAM, swap, 502/504, TTFB en het aantal actieve processen in de FPM-status. Onder de 80 procent RAM-gebruik zonder swap en zonder wachtrijen, ben ik correct. Als er knelpunten optreden tijdens acties zoals afrekenen, zoeken of importeren, pas ik specifiek pm.max_children en pm.max_requests aan. Elke stap wordt uitgevoerd in kleine aanpassingen en met een nieuwe meting.
Geheugenberekening in detail: RSS, PSS en gedeeld geheugen
De procesvariabele is lastig: RSS (Resident Set Size) bevat ook gedeelde segmenten zoals OPcache en bibliotheken. Ik overschat daarom al snel het RAM-verbruik als ik simpelweg „RSS × Kinderen“ bereken. Beter is de PSS-view (Proportional Set Size), die gedeeld geheugen eerlijk verdeelt over processen - hulpmiddelen zoals smem helpen hierbij. De berekening omvat OPcache (bijv. 256 MB + strings), APCu (bijv. 64-128 MB) en het masterproces. De PHP geheugenlimiet is geen gemiddelde, maar de bovengrens per verzoek; er kunnen individuele pieken optreden, maar de gemiddelde waarde telt. Ik plan een buffer zodat pieken, implementaties en cronjobs niet onmiddellijk swaps triggeren, en laat pm.max_aanvragen om geheugenopstapeling te beperken.
WordPress-specifieke belasting verminderen
Ik verlaag eerst de PHP belasting voordat ik de kinderen verder verhoog, omdat een snellere cache hit rate echte tijd bespaart. RAM. Full-page caches zorgen voor een drastische vermindering van PHP-verzoeken, waardoor capaciteit wordt gecreëerd voor checkout, zoeken en admin. OPcache met memory_consumption van 256 MB versnelt de bytecode en ontlast de pool. In de praktijk houd ik de PHP memory_limit op 256M zodat individuele plugins de server niet vertragen. Meer inzicht in bottlenecks is te vinden in de handleiding PHP-worker als bottleneck.
Database en cache backends in balans
Elke PHP-medewerker genereert mogelijk een Databaseverbinding. Als ik pm.max_children verhoog, neemt de gelijktijdige DB-belasting ook toe. Ik controleer daarom MySQL/MariaDB: max_verbindingen, buffer (innodb_buffer_pool_size) en de queryplanner. Redis/Memcached moet het parallel bijhouden. maxclients, geheugenlimiet en latenties. Een WordPress instantie met 20 actieve kinderen kan de DB gemakkelijk verzadigen als er meerdere dure queries parallel worden uitgevoerd. Daarom stem ik de DB af (indexen, langzame queries) en stel ik in op Persistente objectcaches, voordat ik meer kinderen vrijgeef. Dit verhoogt de doorvoer zonder de backend te overbelasten.
WooCommerce, Cron en Admin: speciale gevallen
Winkels genereren meer gelijktijdige dynamische verzoeken, daarom gebruik ik iets Lucht met pm.max_children. Tegelijkertijd heb ik de neiging om pm.max_requests te verlagen om continu het geheugen te sparen. Voor imports en cronjobs plan ik extra budget in of voer ik taken uit buiten de piekuren. Het admingebied piekt vaak op korte termijn; caching biedt hier minder bescherming, dus efficiënt poolbeheer telt. Als er tekenen van wachtrijen zijn, verhoog ik in kleine stapjes en controleer ik de metriek direct daarna.
Containers, vCPU-quota en OOM-vallen
In containers en VM's ligt de nadruk op de effectief RAM-limiet (cgroups), niet op de host. Daarom bereken ik pm.max_children vanaf de toegewezen limiet en niet vanaf „free -h“. Container OOMs zijn genadeloos - de kernel beëindigt processen hard. CPU-quota tellen ook mee: Meer kinderen helpen niet als 1-2 vCPU's de rekentijd beperken. Als vuistregel schaal ik IO-zware WordPress werklasten tot ongeveer 2-4× het aantal vCPU's; daarboven nemen context switches toe, maar niet de echte doorvoer. In georkestreerde omgevingen rol ik veranderingen conservatief uit, observeer pod herstarts en houd readiness/liveness probes zodat korte opwarmfases van FPM niet tellen als fouten.
Foutenbronnen die vaak over het hoofd worden gezien
Veel problemen komen niet voort uit het zwembad, maar uit Plugins, die verzoeken vermenigvuldigen of lange processen genereren. Geïndexeerde zoekopdrachten, gebroken crawlerregels en buitensporige heartbeat-intervallen drijven de belasting op. Ik controleer daarom altijd eerst de logs, query monitor en caching headers. Als de belasting alleen optreedt bij bepaalde URL's, interpreteer ik dit als een indicatie van knelpunten in de plugin of sjablonen. Pas als deze problemen zijn opgelost, schaal ik Kinderen verder.
Inzicht in sessies, admin AJAX en vergrendelingen
WordPress/plugins werken gedeeltelijk met Sessies. Bestandsgebaseerde sessiesloten kunnen verzoeken serialiseren - een enkel traag verzoek blokkeert de rest van dezelfde sessie-ID. Ik houd het sessiegebruik laag en controleer of admin AJAX bursts (wp-admin/admin-ajax.php) onnodig vaak afgaan. De heartbeat moet verstandig worden afgezwakt, anders genereert het belasting zonder toegevoegde waarde. Als er locks of lange bestandstoegangen voorkomen, helpt meer parallellisme niet; caching, snellere opslag-I/O of een andere sessiehandler helpen hier. In logs herken ik zulke patronen van veel gelijksoortige verzoeken die op hetzelfde moment starten met ongewoon lange runtimes.
Nginx, Apache en FastCGI timeouts in een oogopslag
De webserver stelt ook limieten in die ik in overeenstemming moet brengen met de FPM-waarden, anders lopen ze uit. Afstemmen. Bij Nginx let ik op fastcgi_read_timeout en voldoende worker-processen. Bij Apache controleer ik mpm_event, keepalive-instellingen en proxy timeouts. Als deze limieten niet kloppen, melden gebruikers timeouts, ook al heeft FPM nog capaciteit. Gestandaardiseerde tijdbudgetten houden het pad van de client naar PHP consistent.
Uitrolstrategie, tests en werking
Ik rol wijzigingen aan pm.max_children stap voor stap uit en test ze onder echte belasting. Een reload van FPM (graceful) neemt configuraties over zonder de verbinding te verbreken. Voor grotere sprongen simuleer ik pieken (bijv. verkoopstart) en observeer luisterwachtrij, CPU, RAM, 95ste-99ste percentiel van latentie en foutpercentages. Ik documenteer de gemaakte aannames zodat latere teamleden begrijpen waarom een waarde op deze manier is gekozen. Ik stel alarmen in voor: swap > 0, „max children reached“ in de status, toenemende 502/504 en DB latency. Dit zorgt ervoor dat het platform stabiel blijft, zelfs maanden later wanneer het verkeer en de plugin-mix verandert.
Kort samengevat
Verkeerd ingesteld PHP-FPM-kinderen vertragen WordPress, hetzij in wachtrijen of in de RAM-limiet. Ik bepaal de procesgrootte, reserveer geheugen voor systeemservices en stel pm.max_children in met buffer. Vervolgens controleer ik pm.max_requests, request_terminate_timeout en de modus pm = dynamic of static volgens het belastingsprofiel. Caching, OPcache en schone plugins verminderen het aantal PHP-verzoeken merkbaar. Als je deze stappen consequent uitvoert, houd je pagina's responsief en de server betrouwbaar.
