Administration

PHP-FPM-lägen i jämförelse: Statisk, dynamisk och Ondemand

I den här artikeln jämförs PHP-FPM-lägena statisk, dynamisk och på begäran och visar hur de startar processer, binder RAM-minne och påverkar latenstiden. Jag förklarar på ett praktiskt sätt när vilket läge är övertygande, ger förnuftiga startvärden, nämner typiska stötestenar och visar övervakningsknep så att du kan optimera din PHP-pooler på ett säkert sätt.

Centrala punkter

För att du snabbt ska kunna komma igång sammanfattar jag de viktigaste påståendena i ett kompakt format. Fokus ligger på processtyrning, RAM-krav, latens och användningsområden. Varje val har tydliga styrkor, men också begränsningar. Med hjälp av några få nyckeltal kan du fatta tillförlitliga beslut. Så att du kan ta ett fokuserat grepp Tuning och spara tid.

StatiskFast processnummer, maximal konsistens med konstant belastning.
DynamiskAutomatisk skalning mellan minimi- och maximivärden.
OndemandStart vid behov, ekonomisk tomgångskörning, latenstid vid kallstart.
RAM-planering: Tillåt 20-50 MB per process, undvik OOM.
ÖvervakningStatussida, loggar och htop för väl underbyggda beslut.

Hur Process Manager fungerar

PHP-FPM-processhanteraren kontrollerar hur många Arbetare-processer processförfrågningar och när de börjar eller slutar. Varje arbetsinstans har tolkar, tillägg och delar av bytekoden i minnet, vilket vanligtvis innebär några Megabyte bindningar. De tre lägena förändrar startbeteendet, livscykeln och tomgångsbeteendet avsevärt. Static håller ett fast antal aktiva, Dynamic balanserar mellan nedre och övre gränser, Ondemand skapar bara processer när förfrågningar tas emot. Denna kontroll har en direkt effekt på RAM-profil, fördröjning vid uppstart och toppar i systembelastningen.

Viktiga parametrar utgör stommen i din konfiguration: pm definierar läget, pm.max_barn begränsade samtidiga arbetare hårt. Med Dynamic pm.start_servers, pm.min_spare_servers och pm.max_spare_servers som styr buffertens bredd. Ondemand förlitar sig på pm.process_idle_timeout, för att avsluta vilande processer igen. Med vettiga värden kan du se till att belastningstoppar inte leder till flaskhalsar och att maskinen inte utsätts för minnespress.

Jag kontrollerar fotavtrycket per process, den genomsnittliga samtidiga belastningen och toppfördelningen över dagen i förväg. Från dessa variabler härleder jag det maximala värdet för pm.max_barn multiplicera med det uppmätta processminnet och lämna en reserv för webbserver, databas, cache och kernel. Denna enkla beräkning förhindrar out-of-memory-fel och säkerställer Stabilitet under press. Om du tar till dig detta slipper du besväret med att justera i efterhand.

Statiskt läge: konstant effekt vid jämn belastning

Statiskt läge håller ett fast antal PHP-arbetare permanent aktiva, vilket Start-overhead elimineras. Med konstanta trafikprofiler uppnår denna konfiguration mycket låga latensfluktuationer och en konsekvent CPU-belastning. Nackdelen: När RAM-minnet är inaktivt förblir det upptaget även om det inte finns några förfrågningar. Det är därför jag bara väljer Static på värdar med gott om RAM-minne och en beräkningsbar förfrågningsvolym. I butiker eller API-backends som används flitigt ger Static ofta den renaste svarskurvan.

Den avgörande faktorn är en realistiskt inställd pm.max_barn, som är baserad på processens fotavtryck. För den första uppskattningen beräknar jag grovt 20-50 MB per PHP-process inklusive tillägg och OPcache. Jag verifierar det slutliga värdet med belastningstester och systemövervakningen. Om du vill gå in på beräkningen mer i detalj kan du hitta praktiska steg på Optimera pm.max_children. Detta säkerställer att din fasta poolstorlek matchar hårdvaran.

[www]
pm = statisk
pm.max_barn = 50
pm.max_förfrågningar = 500

LedtrådEfter ändringar startar jag om PHP-FPM, kontrollerar loggar och observerar användningen under verklig trafik. Om det fortfarande finns mycket RAM ledigt ökar jag det försiktigt. Om jag ser ökande swap-användning eller OOM killer-poster, minskar jag omedelbart. Denna lilla rutin skyddar Tillgänglighet pålitlig.

Dynamiskt läge: flexibel med fluktuerande efterfrågan

Dynamic börjar med ett fåtal processer och skalar upp Arbetare-nummer inom det definierade intervallet efter behov. Detta minskar tomgångsförbrukningen under lugna faser, medan korta toppar dämpas. Metoden genererar en del overhead under spawning, men får poäng med bra Resurser-effektivitet. I blandade miljöer med dagliga profiler ger Dynamic ofta den bästa kompromissen. Detta läge är fortfarande förstahandsvalet för många CMS-installationer i synnerhet.

Jag har ställt in start-, minimi- och maximivärdena så att det inte inträffar några ständiga „spawn“-händelser under normal belastning. Frekventa loggmeddelanden som "seems busy, spawning children" tyder på att gränserna är för snäva. För WordPress -stackar hjälper det att ställa in cachelagring och OPcache korrekt och sedan öka dem måttligt. En kompakt guide täcker de viktigaste spakarna: Optimerade WordPress-inställningar. Detta gör att du kan uppnå korta svarstider utan att RAM-reservera.

[www]
pm = dynamisk
pm.max_barn = 50
pm.start_servrar = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

TipsObservera de inaktiva arbetarna och de genomsnittliga aktiva processerna under hela dagen. Om medelvärdet ligger nära den övre gränsen, öka måttligt. Om många processer förblir inaktiva sänker du intervallet. Med bara några få iterationer kommer du att träffa Bra plats-inställning.

Ondemand-läge: ekonomiskt i viloläge, start på begäran

Ondemand skapar endast processer när en Förfrågan och avslutar den efter en inaktiv tid. Detta minskar RAM-behovet till ett minimum under lugna faser, vilket gynnar många små webbplatser på en maskin. Under kallstarter uppstår dock ytterligare latens eftersom workern först startar upp och värms upp. För utvecklingsmiljöer, appar som bara körs med cron och sidor som används sällan är den här logiken en Vinst. Jag skulle inte använda Ondemand under kontinuerlig belastning.

[www]
pm = på begäran
pm.max_barn = 50
pm.process_idle_timeout = 10s
pm.max_förfrågningar = 500

Jag brukar ställa in inaktivitetstiden på mellan 10 och 30 sekunder, beroende på samtalsmönster och minnesbudget. En kortare period sparar RAM, men ökar risken för kallstarter. En längre period håller processerna varma, men kostar minne. Jag övervakar därför samtalsfrekvensen, mäter den 95:e percentilens latens och gör sedan finjusteringar. Detta håller Svarstid beräkningsbara utan att belasta systemet.

Jämförelsetabell: Egenskaper för de tre lägena

I följande översikt jämförs typiska egenskaper. Jag använder den som diskussionsunderlag innan jag går in på specifik dimensionering. Tabellen ersätter inte en mätning under verklig belastning, men ger en strukturerad översikt. Startpunkt. Om du justerar värdena bör du alltid hålla ett öga på minnesprofilen och latensfördelningen. Så du håller dig till Toppar och undvika flaskhalsar.

Kriterium	Statisk	Dynamisk	Ondemand
Processer	Fast antal, permanent aktiva	Automatiskt mellan min/max	Starta endast när det behövs
RAM-användning	Ständigt hög	Variabel (t.ex. 200-600 MB)	Minimum i viloläge (t.ex. 50-700 MB)
Prestanda	Mycket jämn	Bra och anpassningsbar	Bra för låg trafik
Idealisk för	Ständiga profiler med hög trafik	Variabel efterfrågan	Många vilande webbplatser / Delad
Overhead	Låg	Medium (spawna/despawn)	Högre för kallstarter

Tabellen hjälper till att kalibrera förväntningarna och tydligt identifiera prioriteringar. Om du vill ha ett så konsekvent svar som möjligt är vinnaren ofta Statisk. Räknar effektivitet med varierande belastning, arbetar Dynamisk oftast trevligare. Om ekonomin är en prioritet finns det ingen väg runt det. Ondemand över. Det är mätvärden som avgör i slutändan, inte antaganden.

Beräkning och dimensionering av resurser

Jag uppskattar först minnesavtrycket per Process multiplicera det med det avsedda antalet arbetare och lägg till 20-30 % reserv. Jag inkluderar även utrymme för Nginx/Apache, databas, Redis/Memcached och kärnan. Denna summa får inte överstiga den fysiska RAM-kapaciteten minus säkerhetsmarginalen. Jag planerar dedikerat minne för OPcache så att bytecode inte förflyttas. Med denna enkla Formel Jag anser att OOM-riskerna är låga.

I nästa steg mäter jag samtidiga förfrågningar via webbserverstatus och APM. Den maximala konkurrensen om PHP-arbetare avgör hur hög pm.max_barn måste vara. Om RAM-minnet inte räcker till ökar jag antalet cacheträffar, förkortar frågetiderna eller flyttar arbete till köer. Först när dessa åtgärder får effekt ökar jag poolen. Detta håller Effektivitet hög och maskinen reagerar tillförlitligt.

Övervakning och felsökning

Bra beslut baseras på Uppgifter. Jag aktiverar PHP-FPM:s statussida och läser av aktiva och inaktiva processer, kölängd och accepterade anslutningar. Jag kontrollerar också felloggar för spawn-varningar och timeouts. I htop övervakar jag CPU-väntan, belastning och swap för att snabbare hitta flaskhalsar. Dessa signaler gör inställningsstegen begriplig och undvik att flyga i blindo.

<?php
$status = @file_get_contents('http://localhost/status');
$data = json_decode($status, true);
echo "Active: " . $data['active processes'] . "\n";
echo "Idle: " . $data['idle processes'] . "\n";
?>

APM-verktyg visar spår och flaskhalsar på funktions- eller frågenivå. Om jag hittar avvikande värden där börjar jag med cachelagring och I/O först. Sedan kontrollerar jag om poolgränserna matchar den faktiska parallelliteten. Först när flaskhalsarna i applikationen har lösts är det värt att göra mer Kapacitet i FPM. Den här processen sparar tid och gör att arkitekturen blir smalare.

Undvik vanliga inställningsfel

Jag ser ofta alltför höga max_barn-värden oberoende av RAM-minnet. Detta skapar onödig swap, långa sophämtningsfaser och i slutändan OOM-dödare. Gränser som är för låga är också skadliga eftersom de bygger upp köer och förlänger svarstiderna. Avsaknad av OPcache slösar också bort CPU-tid och ökar processens fotavtryck. Med några få Kontroller Dessa fällor hålls ur vägen i förväg.

En annan klassiker: olämpliga tidsgränser med Ondemand, som leder till många kallstarter. Här hjälper ett kort A/B-test med 10, 20 och 30 sekunders idle timeout. När det gäller Dynamic leder å andra sidan för små reservvärden till ständiga spawnings. Loggar avslöjar snabbt dessa mönster och vägleder nästa Anpassning på. Detta gör att din stack förblir responsiv.

PHP-FPM i samband med andra PHP-hanterare

PHP-FPM jämförs ofta med gamla CGI-varianter eller moderna alternativ som LSAPI. Valet av hanterare påverkar processhanteringen, Resurser-egenskaper och felisolering. Om du förstår skillnaderna kan du planera buffertar och gränser på ett mer realistiskt sätt. För en snabb överblick är det värt att ta en kort Jämförelse av PHP-hanterare. Efter detta är beslutet till förmån för FPM-lägena tydligt mer målinriktad från.

Jag brukar hålla mig till FPM eftersom det är moget, loggar rent och fungerar bra med Nginx/Apache. Det är inte bara benchmarks som är avgörande, utan även operativa aspekter som observerbarhet och failover. Om dessa grunder är rätt kommer du att få ut mer av statisk, dynamisk eller Ondemand. Alla alternativ förtjänar att testas under verklig belastning. Det är så här du får förtroende för din Inställningar.

Praktisk strategi för beslutsfattande

Jag börjar med Dynamic som Standard, Jag mäter belastningsprofiler och observerar toppar. Om jag ser att användningen är mycket konstant byter jag till Static och ställer in den fasta poolstorleken. Om jag stöter på webbplatser som används sällan väljer jag Ondemand med en lämplig timeout för inaktivitet. Samtidigt optimerar jag OPcache, objektcache och databasfrågor så att FPM utsätts för mindre tryck. Sedan finjusterar jag gränserna så att Köer inte uppstått i första hand.

Denna sekvens minskar risken och ansträngningen. Först mäta, sedan anpassa regler och därefter överväga hårdvara. Jag dokumenterar varje förändring kortfattat med tid, värden och mål. Detta gör det lättare att göra korrigeringar senare och säkerställer en ren Öppenhet. Detta gör att stacken förblir hanterbar, även om trafikmönstren ändras.

Från nyckeltal till tillförlitliga värden: så här räknar jag

Jag översätter belastningsprofiler till konkreta poolstorlekar med hjälp av en enkel tumregel: Hur många förfrågningar kommer per sekund och hur lång tid tar det att behandla dem i genomsnitt eller vid den 95:e percentilen? Jag använder följande som en guide Little's lag i enkel form: samtidig bearbetning ≈ genomströmning × genomsnittlig bearbetningstid. Exempel: 120 förfrågningar/s vid 80 ms i genomsnitt resulterar i cirka 9,6 samtidiga körningar. Jag lägger till 30-50 %-buffertar för toppar och kontrollerar om den resulterande pm.max_barn passar in i min RAM-budget. För hårda toppar inkluderar jag även den 95:e percentilen för att undvika köer.

Det är viktigt att Karaktär av arbetsbelastningen: Med I/O-tunga appar (många fjärranrop, DB-åtkomst) ger något fler arbetare ofta fördelar eftersom väntetiderna överlappas. Med CPU-tung kod begränsar jag mer så att processerna inte saktar ner varandra och körkön inte exploderar.

pm.max_requests: ren återvinning mot fragmentering

Långvariga PHP-processer kan stoppas genom att Fragmentering eller minnesläckor växer. Med pm.max_förfrågningar definierar du efter hur många bearbetade förfrågningar en arbetare ska avslutas och startas om. Detta håller fotavtrycket stabilt. Jag brukar börja på 300-1000, beroende på tillägg och kodbas. Observera processernas RSS/PSS-värden: Om de växer avsevärt, minska värdet. Eftersom OPcache delad bytecode behålls under återvinning av arbetare; de flesta appar märker därför knappt av återvinningen.

[www]
riktad återvinning utan alltför täta omstarter
pm.max_requests = 800

Den som regelbundet Driftsättning drar nytta av en omladdning av poolen. Jag föredrar att använda en elegant omladdning via servicehanteraren (t.ex. „systemctl reload php-fpm“) så att pågående förfrågningar avslutas på ett snyggt sätt och nya arbetare startar med en uppdaterad konfiguration.

Slowlog och timeouts: visualisera flaskhalsar på ett målinriktat sätt

De flesta fördröjningstoppar orsakas av ett fåtal långsamma förfrågningar. Jag aktiverar därför Slowlog med ett måttligt tröskelvärde (t.ex. 2-5 s) och titta på stackspår. Det är så jag hittar problematiska funktioner, externa anrop eller dyra frågor.

[www]
begäran_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/slowlog-www.log

I linje med detta matchar jag Tidsfrister på webbservern. En uppströms timeout (Nginx/Apache) som är för kort jämfört med PHP:s max_execution_time leder till 502/504-fel, även om FPM fortsätter att fungera. Jag håller kedjan konsekvent: Anslutnings-, läs- och sändningstimeouts för webbservern strax över den typiska PHP-förfrågans varaktighet, men under hårda övre gränser.

Korrekt tolkning av värdena för kö, backlog och status

I FPM-statusen ägnar jag särskild uppmärksamhet åt „lyssna kö“ och „max lyssna kö“. Om dessa värden ökar regelbundet är poolen för liten eller blockerad. Kortsiktiga toppar är normala, men permanent överbelastning tyder på underdimensionering. I miljöer med kraftiga störningar ökar jag socketEftersläpning med måtta, bevaka kön och se till att kärnbegränsningar (t.ex. somaxconn) inte är flaskhalsen.

Om övervakningen visar „verkar upptagen, föder barn“ mycket ofta är reservparametrarna (Dynamic) för snäva. Med Ondemand är en återkommande hög andel kallstarter en indikation på att man bör förlänga timeouten för tomgång eller hålla en minsta buffert under dagen.

Flera pooler: Rättvisa, isolering och kvoter

På multi-tenant eller Delad-hosts separerar jag applikationer i egna pooler med individuella gränser. Detta förhindrar att ett minneskrävande projekt tränger ut andra. För kritiska tjänster (t.ex. inloggnings-/API-slutpunkter) planerar jag dedikerade pooler med en fast minimireserv. Tydlig namngivning („www-shop“, „www-api“, „www-cron“) och separata loggar gör det lättare att analysera och hantera data. FelSök.

Se till att summan av alla pm.max_barn passar maskinen över alla pooler. Jag köper också Limiter nedströms på: DB-max_anslutningar, Redis/Memcached-trådning och externa API-priser. En PHP-pool som avfyrar fler samtidiga förfrågningar än databasen kan hantera köper sig bara längre köer.

Tame OPcache uppvärmning, förladdning och kallstarter

På Ondemand-för att motverka kallstarter håller jag OPcache stabil (tillräcklig minne_förbrukning och interned_strings_buffer) och, om så är lämpligt, ställ in till Förspänning centrala klasser/ramverk. Detta innebär att bytekod är tillgänglig efter första träffen och att repetitioner förblir varma. Dessutom bidrar en större realpath-cache och en strukturerad autoloader till att minska antalet uppslagningar i filsystemet. Sammantaget förkortar detta avsevärt uppstartstiden för nystartade arbetare.

Webbserverinteraktion: Anslut Nginx/Apache på ett rent sätt

Jag ser till att inställningarna för webbservern och FPM stämmer överens: Buffert och Tidsfrister måste vara symmetriska, keep-alive får inte blockera FPM med zombieanslutningar och uppströms socket (Unix eller TCP) måste konfigureras konsekvent. Många 502/504-fel orsakas av felaktigt inställda lästimeouts eller uttömda backlogs. Alla som adresserar FPM via TCP bör överväga latensen i nätverksstacken och risken för halvöppen Håll ett öga på anslutningarna; jag brukar föredra Unix-sockets för lokala installationer.

Container/VM-specialfunktioner

I containrar är cgroup-gränser, inte nödvändigtvis värdvärdena. Jag dimensionerar pooler uttryckligen för container-RAM och använder artificiella belastningstoppar för att testa om OOM-killers kan få effekt. En gräns som är för snäv leder till hårda avbokningar. Att byta ut containrar är ofta inte heller önskvärt - så det är bättre att vara lite mer konservativ med pm.max_barn planera och prioritera cachelagring av applikationer.

Identifiera CPU- och I/O-karaktär

Jag använder htop/iostat för att bedöma om arbetsbelastningen är CPU- eller är I/O-bundna. Högt CPU-användande med låga I/O-väntor indikerar en datorbelastning - här begränsar jag antalet arbetare närmare antalet kärnor. Höga I/O-väntor motiverar fler arbetare eftersom väntetiderna i databasen, nätverket eller filsystemet överlappar varandra. Du kan känna igen gränsen genom att latensen inte längre minskar trots ytterligare medarbetare, utan belastningen ökar avsevärt.

Snabbt avkoda typiska 502/504-mönster

504 Gateway timeout: Webserver timeout mindre än PHP exekveringstid eller blockerad pool (kö full).
502 Dålig gateway: FPM inte nåbar (socket/port), krasch/omstart under begäran eller för liten buffert.
Toppar strax efter driftsättning: OPcache kall, kontrollera optimeringar för autoloader/kompositör, schemalägg uppvärmning.

Jag korrelerar webbserverns fellogg, FPM-felloggen och statussidan i samma tidsfönster. Detta visar om problemet uppstod före, under eller till FPM är lokaliserad.

Mätning av handel: Korrekt redovisning av lagringskostnader

För RAM-planering tittar jag inte bara på RSS, utan också på PSS (Proportional Set Size) eftersom det fördelar delade sidor (t.ex. OPcache) rättvist över processer. Verktyg som t.ex. smem eller pmap hjälper till att fastställa realistiska processrelaterade värden. I praktiken räcker det dock ofta med slumpmässiga stickprov under belastning: markera flera processer, beräkna genomsnittet, jämför med Reserv multiplicera - detta återspeglar verkligheten bättre än teoretiska värden från forum.

Mini checklista för snabba iterationer

Registrera belastningsprofil (RPS, 50/95/99 percentil, parallellism).
Mäta processavtryck (PSS, inte bara RSS) och pm.max_barn med reservation.
Välj det läge som passar mönstret: Statisk (konstant), Dynamisk (växlande), Ondemand (mycket inaktiv tid).
pm.max_förfrågningar ställ in, observera arbetarnas tillväxt, justera vid behov.
Dimension OPcache och kontrollera uppvärmning/förladdning för att minska kallstarter.
Aktivera statussida och slowlog, analysera kö och spawn-meddelanden.
Synkronisera webbserverns timeouts och buffertar mot FPM- och app-tider.
Harmonisera gränser med nedströms system (DB, cacher, externa API:er).
Dokumentera ändringar, mäta och upprepa efter driftsättningar.

Kompakt sammanfattning

Statisk ger den jämnaste svarstiden och passar för konstant trafik med gott om RAM-minne. Dynamisk balanserar flexibilitet och effektivitet och får höga poäng vid förändrade mönster. Ondemand sparar minne när den är inaktiv och är lämplig för många vilande webbplatser, men det sker på bekostnad av latens vid kallstart. Med ren resursberäkning, övervakning och små iterationer kan du fatta tillförlitliga beslut. Håll processerna så små som möjligt, använd OPcache och välj det läge som passar dina verkliga behov. Profil passar.

Med dessa skyddsräcken kan du uppnå stabil prestanda med rimlig förbrukning. Konfiguration är ingen gissningslek när siffrorna ligger på bordet. Små steg har ofta störst effekt. Mät, justera och dokumentera. Så din PHP-FPM-pooler snabbt, ekonomiskt och förutsägbart.