Hoppa till innehåll 
PHP-FPM Barn bestämmer i WordPress om förfrågningar går smidigt eller fastnar i kön. Jag ska visa dig hur felaktiga pm.max_barn-värden blockerar sidor, tar RAM-minne i anspråk och hur jag beräknar rena värden.
Centrala punkter
Innan jag går djupare ska jag kort sammanfatta de viktigaste budskapen:
- pm.max_barn avgör hur många samtidiga PHP-förfrågningar som körs.
- För lite Barn genererar köer, 502/504 och hög TTFB.
- För mycket leder till RAM-flaskhalsar, swap och OOM-död.
- Formeltillgängligt PHP RAM / processstorlek × 0,7-0,8.
- Iterativ Tuning med övervakning ger bästa möjliga prestanda på lång sikt.
Varför felaktiga PHP-FPM Children-sidor blockeras
Varje dynamisk WordPress-begäran kräver sin egen Arbetare, och det är just dessa processer som poolen kontrollerar via pm.max_children. Om jag sätter värdet för lågt samlas förfrågningar i en kö och TTFB ökar märkbart. Om jag ställer in värdet för högt använder varje barnprocess ytterligare RAM-minne och servern växlar till swap. Allt går långsammare i swappen tills Apache eller Nginx rapporterar 502/504 eller OOM-dödaren avslutar processer. Hälsosam genomströmning uppnås endast när antalet barn matchar den verkliga RAM-budgeten och projektets belastning.
Formeln för pm.max_children i praktiken
Jag börjar med den enkla formeln: tillgängligt RAM-minne för PHP dividerat med den genomsnittliga storleken på en barnprocess, multiplicerat med ett Säkerhetsfaktor Jag bestämmer RAM-minnet per process med ps och RSS-kolumnen; för typiska WordPress-stackar är 50-250 MB ofta korrekt. På en 4 GB-server reserverar jag minne för Linux-, databas- och cachetjänster och lämnar cirka 1,5-2 GB för PHP kvarstår. Om processgenomsnittet till exempel är 100 MB blir 2 000 / 100 × 0,75 = 15 barn. Denna siffra fungerar som en utgångspunkt, som jag förfinar beroende på belastningsprofil, cachning och plugin-mix.
Startvärden för typiska WordPress-installationer
För små bloggar med 2 GB RAM, 8 barn, pm = dynamic och en pm.max_requests på ca. 800. För medelstora projekt med 4 GB RAM ställer jag in 12 barn, start_servers 4, min_spare_servers 4. Stora butiker med 8 GB RAM eller mer har nytta av 21-40 barn; om belastningen är permanent hög kan pm = static säkerställa konstant genomströmning. Jag kontrollerar sedan förhållandet mellan CPU-användning, RAM-användning och svarstider för att kunna göra finjusteringar. Om du vill fördjupa dig kan du hitta bakgrundsinformation på optimala PHP-FPM-inställningar.
Mätning av processer: Hur man fastställer RAM-krav
Jag bestämmer först processernas verkliga storlek innan jag fastställer värdena, eftersom kristallkulor inte är till någon hjälp här och dessutom kostar pengar. Effekt. Kommandot ps -ylC php-fpm -sort:rss returnerar RSS-storlekarna, som jag övervakar under några minuter. Processer växer ofta under uppdateringar eller cron-jobb, vilket är anledningen till att jag inkluderar spikar i beräkningen. Jag använder också htop och free -h för att kontrollera RAM-minnesreserverna och mängden swap. Jag använder dessa data för att fastställa ett tillförlitligt genomsnitt och välja en konservativ säkerhetsfaktor.
Viktiga parametrar i en överblick
Förutom pm.max_children avgör andra poolalternativ hur rent WordPress behandlar förfrågningar och hur väl det frigör minne, vilket märkbart minskar Stabilitet pm reglerar läget: dynamic anpassar antalet processer till belastningen, static bibehåller ett fast antal. pm.max_requests förhindrar minnesuppblåsning genom att starta om processer efter X förfrågningar. request_terminate_timeout skyddar mot avbrott som orsakas av felaktiga eller långsamma skript. Med den här uppsättningen täcker jag 90 procent av de verkliga praktiska fallen.
| Parametrar | Funktion | WordPress rekommendation |
|---|---|---|
| pm | Läge för processtyrning | dynamisk för varierande belastning; statisk för permanent hög trafik |
| pm.max_barn | Maximalt antal samtidiga arbetare | Tillgängligt PHP RAM / processstorlek × 0,75 |
| pm.max_förfrågningar | Återvinning av processer | 300-1.000; snarare lägre med WooCommerce |
| begäran_avsluta_timeout | Avbokning av långvariga förfrågningar | 60-120 sekunder mot hängare |
Dynamiskt, on demand eller statiskt - vilket läge är rätt för dig?
Jag väljer läge för att matcha lastprofilen: dynamisk är min standard, eftersom den flexibelt anpassar antalet aktiva processer och därmed sparar RAM när det inte händer så mycket. statisk Jag använder det när belastningen är konstant och jag behöver hårda åtaganden när det gäller latens och genomströmning - till exempel under kampanjer eller försäljning. på begäran är lämplig för servrar med långa inaktivitetsfaser: Processer skapas bara när de behövs och avslutas igen efter inaktivitet. Avvägningen är kallstarter; den första förfrågan per ny process känns långsammare. För ondemand ställer jag in pm.process_idle_timeout rent (t.ex. 10-20s), med dynamik håller jag starta_servrar, min_spare_servrar och max_spare_servrar smal så att poolen skalar snabbt men inte „sväller“.
Exempel på konfiguration för din pool
På Debian/Ubuntu finns poolfilen vanligtvis under /etc/php/8.x/fpm/pool.d/www.conf, vilket ger mig en tydlig Struktur för anpassningar. Jag ställer in pm på dynamisk, förankrar ett realistiskt värde för pm.max_children och håller reservservern tät. Jag ställer in återvinningen till 500 för att tidigt begränsa läckage och RAM-ökningar. Efter varje ändring testar jag belastningen och åtgärdar flaskhalsar innan jag ökar värdena ytterligare. För bakgrundsinformation om gränsvärden, insikten på Optimera pm.max_children.
pm = dynamisk
pm.max_barn = 15
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_förfrågningar = 500
begäran_avsluta_timeout = 90s
Flera pooler, uttag och ren isolering
För flera projekt eller tydligt åtskilda roller (frontend vs. admin/REST), sätter jag upp separata pooler med sin egen användare och socket. På så sätt begränsar varje pool sina egna barn och en avvikare blockerar inte resten. På en värd föredrar jag Unix-uttag jämfört med TCP (listen = /run/php/site.sock) - lägre latens, mindre overhead. Jag använder TCP mellan Nginx/Apache och PHP-FPM på olika värdar/containrar. Jag använder listen.ägare, listen.group och listen.mode konsekvent och, om nödvändigt, höja listen.backlog så att korta belastningstoppar inte leder till anslutningsfel. Med en dedikerad administratörspool kan jag uppnå en stramare begäran_avsluta_timeout drivning och pm.max_förfrågningar lägre utan att sakta ner den caching-starka frontend-poolen.
Känna igen symtom och reagera på rätt sätt
Om det regelbundet står „server reached pm.max_children“ i felloggen begränsar poolen antalet Parallellism och jag ökar den måttligt. Om 502/504 inträffar samtidigt som swap-användningen är hög återställer jag pm.max_children och sänker pm.max_requests. Om CPU ökar med låg RAM-användning blockeras vanligtvis frågor eller PHP-logik; jag optimerar databasen och cachningen. Om förfrågningar fastnar kan en striktare request_terminate_timeout och logganalys med tidsstämplar hjälpa. Jag kontrollerar iögonfallande toppar mot cronjobs, sökindex och adminåtgärder.
FPM-status och slowlog: exakt diagnos
Jag aktiverar Status per pool (pm.status_path) och läsa nyckeltal som t.ex. aktiva processer, max antal barn som nås, lyssna kö och max lyssna kö av. En permanent växande listkö visar tydligt: för få barn eller blockerande backends. Jag ställer också in begäran_slowlog_timeout (t.ex. 3-5 år) och en slowlog-väg. Det är så här jag ser stackspår av förfrågningar som dröjer - ofta externa HTTP-anrop, komplexa WooCommerce-frågor eller bildmanipulationer. Med catch_workers_output varningar från arbetarna samlas in i loggarna. Baserat på dessa data bestämmer jag om mer parallellism hjälper eller om jag behöver lösa flaskhalsar i koden/DB:n.
Övervakning: 3-5 dagar ren utvärdering
Efter inställningen observerar jag belastningstoppar under flera dagar, eftersom kortsiktiga fluktuationer lura. Jag loggar RAM, swap, 502/504, TTFB och antalet aktiva processer i FPM-status. Under 80 procents RAM-användning utan swap och utan köer har jag rätt. Om det uppstår flaskhalsar vid åtgärder som utcheckning, sökning eller import justerar jag specifikt pm.max_children och pm.max_requests. Varje steg utförs i små justeringar och med en ny mätning.
Minnesberäkning i detalj: RSS, PSS och delat minne
Processvariabeln är knepig: RSS (Resident Set Size) innehåller även delade segment som OPcache och bibliotek. Därför överskattar jag snabbt RAM-förbrukningen om jag bara räknar ut „RSS × Children“. Bättre är att PSS-view (Proportional Set Size), som fördelar delat minne rättvist mellan processer - verktyg som smem hjälper till här. Beräkningen inkluderar OPcache (t.ex. 256 MB + strängar), APCu (t.ex. 64-128 MB) och masterprocessen. PHP memory_limit är inte ett genomsnitt, utan den övre gränsen per begäran; enskilda toppar kan förekomma, men det är medelvärdet som räknas. Jag planerar en buffert så att spikar, driftsättningar och cronjobs inte omedelbart utlöser byten, och lämnar pm.max_förfrågningar för att begränsa minnesuppblåsning.
Minska WordPress-specifik belastning
Jag minskar PHP-belastningen först, innan jag ökar antalet barn ytterligare, eftersom en snabbare cache-träfffrekvens sparar realtid. RAM. Cacher på hela sidan minskar drastiskt PHP-förfrågningar, vilket skapar kapacitet för utcheckning, sökning och administration. OPcache med memory_consumption på 256 MB accelererar bytekoden och avlastar poolen. I praktiken håller jag PHP memory_limit på 256M så att enskilda plugins inte saktar ner servern. Mer insikt om flaskhalsar finns i guiden PHP-Worker som flaskhals.
Balans mellan databas- och cache-backends
Varje PHP-medarbetare genererar potentiellt en Anslutning till databas. Om jag ökar pm.max_children ökar också den samtidiga DB-belastningen. Jag kontrollerar därför MySQL/MariaDB: max_anslutningar, buffert (innodb_buffer_pool_size) och frågeplaneraren. Redis/Memcached måste hålla jämna steg parallellt - maxclients, minnesgräns och latenser. En WordPress-instans med 20 aktiva barn kan enkelt mätta DB om flera dyra frågor körs parallellt. Det är därför jag justerar DB (index, långsamma frågor) och ställer in till Beständiga objektcacher, innan jag släpper fler barn. Detta ökar genomströmningen utan att överbelasta backend.
WooCommerce, Cron och Admin: specialfall
Butiker genererar fler samtidiga dynamiska förfrågningar, vilket är anledningen till att jag använder något Luft med pm.max_children. Samtidigt tenderar jag att sänka pm.max_requests för att kontinuerligt minska minnesuppblåsningen. För import och cronjobs planerar jag ytterligare budget eller utför uppgifter utanför topptimmarna. Adminområdet får ofta toppar med kort varsel; här ger cachelagring mindre skydd, så effektiv poolkontroll räknas. Om det finns tecken på köer ökar jag i små steg och övervakar mätvärdena omedelbart efteråt.
Containrar, vCPU-kvoter och OOM-fällor
I containrar och virtuella datorer ligger fokus på effektiv RAM-gräns (cgroups), inte på värden. Jag beräknar därför pm.max_children från den tilldelade gränsen och inte från „free -h“. Container OOMs är skoningslösa - kärnan avslutar processer hårt. CPU-kvoter räknas också: Fler barn hjälper inte om 1-2 vCPU:er begränsar datatiden. Som en tumregel skalar jag IO-tunga WordPress-arbetsbelastningar till cirka 2-4 × antalet vCPU: er; över detta ökar kontextväxlingarna, men inte den verkliga genomströmningen. I orkestrerade miljöer rullar jag ut ändringar på ett konservativt sätt, observerar omstarter av poddar och behåller prober för beredskap/livslängd så att korta uppvärmningsfaser av FPM inte räknas som fel.
Felkällor som ofta förbises
Många problem härrör inte från poolen, utan från Insticksprogram, som multiplicerar förfrågningar eller genererar långa processer. Indexerade sökningar, brutna crawler-regler och överdrivna heartbeat-intervaller driver upp belastningen. Därför kontrollerar jag alltid loggar, query monitor och cachelagringsrubriker först. Om belastningen bara uppstår med vissa webbadresser tolkar jag detta som en indikation på flaskhalsar i plugin eller mall. Först när dessa problem har lösts skalar jag Children ytterligare.
Förstå sessioner, admin AJAX och lås
WordPress/plugins arbetar delvis med Sessioner. Filbaserade sessionslås kan serialisera förfrågningar - en enda långsam förfrågan blockerar resten av samma sessions-ID. Jag håller sessionsanvändningen låg och kontrollerar om admin AJAX-bursts (wp-admin/admin-ajax.php) avfyras onödigt ofta. Heartbeat bör strypas på ett förnuftigt sätt, annars genererar det belastning utan mervärde. Om det förekommer låsningar eller långa filåtkomster hjälper det inte med mer parallellism, utan här hjälper cachelagring, snabbare lagrings-I/O eller en annan sessionshanterare. I loggar känner jag igen sådana mönster från många liknande förfrågningar som startar samtidigt med ovanligt långa körtider.
Översikt över timeouts för Nginx, Apache och FastCGI
Webbservern sätter också gränser som jag måste harmonisera med FPM-värdena, annars kommer de att försvinna. Tuning. Med Nginx är jag uppmärksam på fastcgi_read_timeout och tillräckligt med arbetsprocesser. Under Apache kontrollerar jag mpm_event, keepalive-inställningar och proxy-timeouts. Om dessa gränser inte är korrekta rapporterar användarna timeouts trots att FPM fortfarande har kapacitet. Standardiserade tidsbudgetar håller vägen från klienten till PHP konsekvent.
Strategi för utrullning, tester och drift
Jag rullar ut ändringar av pm.max_children steg för steg och testar dem under verklig belastning. En omladdning av FPM (graceful) tar över konfigurationer utan att bryta anslutningen. Före större hopp simulerar jag toppar (t.ex. försäljningsstart) och observerar följande lyssna kö, CPU, RAM, 95:e-99:e percentilen av latens- och felfrekvenser. Jag dokumenterar de antaganden som görs så att senare teammedlemmar förstår varför ett värde väljs på det här sättet. Jag ställer in larm för: swap > 0, „max children reached“ i statusen, ökande 502/504 och DB-latenscy. Detta säkerställer att plattformen förblir stabil även månader senare när trafiken och plugin-mixen ändras.
Kortfattat sammanfattat
Felaktigt inställd PHP-FPM-barn gör WordPress långsammare, antingen i köer eller i RAM-gränsen. Jag bestämmer processstorleken, reserverar minne för systemtjänster och ställer in pm.max_children med buffer. Sedan kontrollerar jag pm.max_requests, request_terminate_timeout och läget pm = dynamisk eller statisk enligt belastningsprofilen. Caching, OPcache och clean plugins minskar märkbart antalet PHP-förfrågningar. Om du genomför dessa steg konsekvent kommer du att hålla sidorna responsiva och servern tillförlitlig.
