Kapacitetsplanering för PHP-FPM: Beräkna antalet arbetare, RAM-minne och samtidiga förfrågningar

Vad som begränsar en PHP-FPM-arbetare

PHP-FPM hanterar PHP-processer i pooler. En Arbetare behandlar en förfrågan i taget; inställningen för poolen pm.max_children begränsar antalet samtidigt tillgängliga arbetare och därmed antalet PHP-förfrågningar som bearbetas samtidigt i denna pool. Om det finns flera pooler gäller gränsen för respektive pool, inte automatiskt för hela servern.

Denna siffra är varken antalet inloggade besökare eller ett direkt mått på antalet förfrågningar per sekund. En besökare kan generera flera förfrågningar, medan en inloggad användare inte upptar en worker mellan två åtgärder. Omvänt kan en enda långsam förfrågan uppta en worker under en längre tid än flera korta förfrågningar i följd.

Det är inte heller så att varje sidvisning når PHP-FPM. Om webbservern levererar en statisk fil direkt eller om en uppströms cache besvarar en förfrågan fullständigt krävs, beroende på arkitekturen, ingen PHP-worker för detta. Cache-missar, inloggade användare och administrationssidor kan däremot fortfarande generera PHP-förfrågningar och tillfälligt öka belastningen.

För kapacitetsplaneringen är därför två separata frågor avgörande: Hur många arbetare ryms, inklusive reserv, i det tillgängliga RAM-minnet? Och hur många arbetare krävs för den trafik som faktiskt anländer till poolen, så att förfrågningarna inte får vänta orimligt länge? Ett högt värde för pm.max_children besvarar ingen av dessa frågor på egen hand.

Även om det finns tillräckligt med lagringsutrymme kan processorn, databasen eller externa tjänster begränsa den faktiska kapaciteten. Ytterligare arbetare möjliggör visserligen mer parallell PHP-bearbetning, men kan samtidigt öka belastningen på en tjänst som redan är långsam. Poolvärdet är därför en driftsgräns och inte ett prestandalöfte.

Förstå processhanteraren och köerna

Der Processansvarig anger när PHP-FPM ska tillhandahålla arbetare. Vid static motsvarar det angivna processnumret värdet av pm.max_children. Det gör att antalet processer blir lättare att planera, men binder samtidigt resurser även vid låg belastning. Övre gränsen måste fortfarande stämma överens med det tillgängliga lagringsutrymmet.

Med dynamic justerar FPM processantalet: startantalet samt det minsta och största antalet lediga arbetare ställs in separat. Vid ondemand Arbetare skapas först vid behov och avslutas efter en konfigurerad vilotid. Detta kan spara resurser i pooler som sällan används; vid en plötslig belastningstopp måste dock först ny processkapacitet skapas.

Om alla arbetare är upptagna kan ytterligare förfrågningar i Lyssnar-kö vänta på en ledig process. FPM-statusen visar bland annat den aktuella och den maximala köngden. Ett enskilt högt maximivärde säger dock inte om poolen just nu är överbelastad; för att kunna avgöra det krävs en tidsreferens.

En längre kö skapar inga ytterligare arbetare och påskyndar inte en långsam databas. Den kan tillfälligt ta emot förfrågningar, men flyttar bara väntetiden till tiden före PHP-bearbetningen. För valet av processhanterare är därför både den typiska belastningsutvecklingen och konsekvenserna av korta toppar viktiga.

Att klassificera arbetarminnet korrekt

En workers minnesbehov kan inte på ett tillförlitligt sätt fastställas enbart utifrån en gräns i PHP-konfigurationen. För planeringen är processdata under lämpliga belastningsförhållanden mer användbara. Det spelar roll om du tittar på det residenta minnet för en enskild process eller om du vill uppskatta minnesförbrukningen för en hel grupp av PHP-FPM-workers.

RSS beskriver en processens residenta minne. Om flera arbetare använder samma minnessidor kan dessa ingå i deras respektive RSS. Om du summerar RSS-värdena för alla arbetare kan gemensamt använda sidor därför i vissa fall räknas med flera gånger; summan ger därför ingen korrekt bild av det gemensamt upptagna fysiska minnet.

PSS fördelar delade sidor proportionellt mellan de deltagande processerna. Summan av PSS-värdena för en processgrupp är därför ofta mer användbar för minnesplaneringen än summan av RSS-värdena. Den förblir dock en ögonblicksbild: om antalet processer som delar sidorna förändras, förändras också de respektive andelarna.

Beakta flera arbetare vid både typiska och minneskrävande förfrågningar. En nystartad process eller ett enskilt genomsnitt kan underskatta det framtida behovet. Den totala pool-PSS vid olika antal arbetare och belastningsförhållanden hjälper till att härleda ett konservativt approximativt värde; en extrapolering till fler arbetare är osäker på grund av varierande gemensamma och privata andelar.

PHP-memory_limit är inte en tillförlitlig uppgift för hela operativsystemets minne i en FPM-process och ersätter inte denna observation. Delat minne, till exempel via OPcache, bör du inte generellt dra av en andra gång från budgeten om det redan ingår proportionellt i den använda pool-PSS:en. Andra tjänster och en reserv måste ändå beaktas.

Beräkna RAM-budget och antal arbetare

Utgångspunkten är det faktiskt tillgängliga RAM-minnet: på en värd är det det minne som kan användas för tjänsterna, i containern är det den effektiva minnesgränsen. Dra av behovet för operativsystemet, webbservern, en eventuell lokal databas och övriga tjänster från detta. Andra FPM-pooler och en reserv för varierande förbrukning ska också tas med i beräkningen.

Den återstående delen är Poolbudget. För att uppskatta antalet arbetare observerar du PSS-summan för poolens arbetare vid olika antal processer och belastningsförhållanden. Ta hänsyn till både typiska förfrågningar och minneskrävande slutpunkter. Dela respektive summa med det aktuella antalet arbetare och härled ett försiktigt approximativt värde utifrån flera observationer.

Följande beräkning är ett illustrativt räkneexempel, inte en mätning. De antagna värdena tjänar endast till att visa beräkningsmetoden; de utgör inte någon rekommendation för en specifik tillämpning. Resultatet avrundas till ett helt antal arbetare.

De 25 arbetarna utgör ingen garanti för en säker tilldelning. PSS fördelar delade sidor proportionellt och förändras beroende på antalet processer som delar dessa sidor. Även en annan sammansättning av förfrågningar kan påverka behovet av privat minne; beräkningen bör därför jämföras med den observerade totala förbrukningen och den befintliga gränsen.

Om delat minne, såsom OPcache, redan ingår proportionellt i den använda PSS-summan, ska du inte dra av det ytterligare som en helt extra post. Planera ändå in en reserv för minnesandelar som inte omfattas av din beräkning. Särskilt vid en containergräns är det i slutändan förbrukningen av alla processer inom gränsen som räknas, inte bara den uppskattade summan av arbetare.

En nystartad worker i sig är inte särskilt meningsfull som underlag: den har kanske ännu inte bearbetat någon krävande begäran. Jämför därför flera tidpunkter och notera vilka slutpunkter och hur många arbetare som var inblandade vid varje tillfälle. På så sätt kan man se om det valda approximativa värdet även håller vid mindre gynnsamma, men realistiska driftsförhållanden.

Uppskatta behovet av arbetare utifrån förfrågningar

RAM-beräkningen beskriver hur många arbetare som förväntas få plats. Behovet beräknas däremot utifrån hur många PHP-förfrågningar som faktiskt anländer till den aktuella poolen och hur länge de upptar en arbetare. En första uppskattning är: genomsnittligt antal samtidigt upptagna arbetare är lika med antalet PHP-förfrågningar per sekund multiplicerat med den genomsnittliga arbetstiden per arbetare i sekunder.

Illustrativt räkneexempel, ingen mätning: Om man antar 20 PHP-förfrågningar per sekund och en genomsnittlig bearbetningstid på 0,25 sekunder är i genomsnitt fem arbetare sysselsatta. Detta är ett genomsnitt över den betraktade tidsperioden. Det innebär varken att exakt fem processer alltid är aktiva, eller att fem är tillräckligt som poolgräns för korta toppar.

När det gäller antalet förfrågningar ska du inte räkna med alla sidvisningar utan att kontrollera dem. Om en cache levererar många svar utan att anropa PHP belastar dessa träffar inte poolen. Omvänt kan cache-missar, inloggade besökare och administratörsåtkomst tillfälligt utlösa mer PHP-arbete än vad ett genomsnitt över hela dagen skulle antyda.

Die Arbetstagarens arbetstid omfattar även väntetider under bearbetningen, till exempel på en databas eller en extern tjänst. Den är inte automatiskt likställd med den svarstid som visas i webbläsaren. Enligt fastcgi_finish_request() PHP kan redan ha skickat svaret till klienten och ändå fortsätta att utföra ytterligare uppgifter i arbetaren.

För att uppnå acceptabla väntetider behöver du ett marginalutrymme utöver den genomsnittliga beläggningen. Hur stort detta marginalutrymme måste vara beror bland annat på belastningsvariationer, långsamma slutpunkter och det önskade svarsmålet. Att multiplicera antalet toppförfrågningar per sekund med en hög latenspercentil kan vara en försiktig scenariebedömning, men är ingen exakt prognos för köerna.

Betrakta därför flera tidsperioder separat: En kort trafiktopp och en lugn natttrafik kan ge samma dagsmedelvärde som en jämnare trafik, men ställer olika krav. Om beläggningstiden ökar på grund av en långsam backend ökar även det genomsnittliga antalet upptagna arbetare vid samma ankomstfrekvens. Behovet beror alltså inte enbart på besökarflödet.

Hämta poolinställningar från planeringen

Jämför nu den RAM-baserade övre gränsen med det uppskattade behovet, inklusive en viss marginal. Om behovet ligger under den gränsen, välj ett försiktigt startvärde för pm.max_children, som inte behöver utnyttja hela budgeten. I det illustrativa exemplet skulle 25 vara den beräknade RAM-gränsen, men inte nödvändigtvis den lämpliga inställningen; CPU och backend kan sätta gränser redan innan dess.

Om det uppskattade behovet överstiger RAM-gränsen löser en högre gräns inte problemet: det kan utsätta värden eller containern för minnesbelastning. Omvänt kan en mycket låg gräns leda till att förfrågningar får vänta. Förbättra i så fall exempelvis exekveringstiden eller cacheanvändningen och kontrollera om ytterligare resurser eller en begränsning av inkommande belastning behövs.

Med dynamisk Här anger du, förutom den övre gränsen, antalet startprocesser samt minimi- och maximiantalet lediga arbetare. Start- och reservvärdena bör anpassas efter den förväntade belastningen och ligga inom den övre gränsen. För liten reservkapacitet kan innebära ett extra startbehov vid plötslig belastning; å andra sidan förbrukar ett stort antal lediga processer resurser på lång sikt.

Med på begäran Arbetare skapas först vid behov; vilotiden fram till dess att de avslutas ställs in separat. Detta kan vara lämpligt för pooler som sällan används, men kräver särskild uppmärksamhet vid snabba belastningsökningar. Även här begränsar pm.max_children antalet arbetare i poolen som är tillgängliga samtidigt.

Flera webbplatser på samma värd får inte var för sig tillgång till allt ledigt RAM-minne oberoende av varandra. Budgetera deras möjliga poolgränser tillsammans med de övriga tjänsterna och reserven. En eventuellt konfigurerad global FPM-processgräns kan dessutom tillämpas, men ersätter varken de enskilda poolbudgetarna eller kontrollen av CPU- och databaskapaciteten.

Kontrollera den faktiska belastningen och väntetiderna under lämpliga tidsperioder efter ändringar, istället för att betrakta startvärdet som slutgiltigt. Vid managed hosting är processdata eller poolinställningar eventuellt inte direkt tillgängliga; använd då leverantörens mätvärden och tillgängliga alternativ. Vilka inställningar som är tillgängliga beror dessutom på PHP-versionen och driftsmiljön.

Övervaka FPM-status och lagringsutrymme

FPM-statussidan visar om de planerade arbetarna räcker till under verklig belastning. Skydda statusändpunkten från allmän åtkomst: Den kan avslöja känslig information om förfrågningar och resurser. En separat konfigurerad statuslyssnare kan förbli tillgänglig även när huvudpoolen är överbelastad; kontrollera dess tillgänglighet och inställningar för din PHP-version och webbserverkonfiguration.

Betrakta värdena som tidsserier tillsammans med förfrågningsvolym och svarstider. Ett gammalt högsta värde för köen bevisar inte någon aktuell överbelastning; på samma sätt är ökningen av räknarna sedan den senaste mätningen mer talande än det rena totalvärdet. Ta hänsyn till poolstart respektive omstarter, som förändrar referensperioden.

För en känd FPM-process kan du på ett Linux-system med tillgängligt proc-gränssnitt läsa av aggregerade minnesvärden. Ersätt PID genom det faktiska process-ID:t; du måste ha motsvarande åtkomsträttigheter. Upprepa mätningen för flera arbetare och belastningsförhållanden, istället för att utgå från en enskild process för att fastställa en permanent poolstorlek.

cat /proc/PID/smaps_rollup

Undersöka långsamma förfrågningar och köer

En webbutik kan visa många aktiva arbetare, även om det inte är själva PHP-körningen som utgör den ursprungliga flaskhalsen. Om förfrågningar väntar på långsamma databasfrågor förblir arbetarna upptagna under tiden. Om ytterligare förfrågningar kommer in kan lyssnarens kö växa och svarstiden öka, även om CPU:n fortfarande har ledig kapacitet.

En högre gräns för antalet arbetare kan i denna situation möjligen leda till att fler förfrågningar samtidigt når databasen. Detta kan Backend-utskrift och förlänga väntetiderna ytterligare. Jämför därför utvecklingen över tid av FPM-belastningen och köerna med databasbelastningen, långsamma sökningar och externa tjänsteanrop innan du höjer gränsen.

FPM-Slowlog hjälper till att identifiera långa PHP-anrop: För förfrågningar som överskrider ett konfigurerat tröskelvärde kan FPM logga en backtrace. Denna visar en exekveringspunkt och är inte en fullständig profil av hela förfrågan. Återkommande ställen kan jämföras med förfrågningens varaktighet och backend-mått; de Anvisningar för att analysera PHP-FPM:s slowlog förklarar den vidare analysen.

Även en timeout ska skiljas från den faktiska kapaciteten. I nginx betecknas fastcgi_read_timeout det tillåtna avståndet mellan på varandra följande läsningar från FastCGI-servern, inte den totala begärandetiden generellt sett. Ett högre värde kan medföra längre väntetider, men skapar varken ytterligare arbetare eller påskyndar databasen.

Kapacitetsbegränsningar och nästa steg

Om RAM-budgeten inte räcker till det beräknade behovet, löser en högre inställning för pm.max_children Ta inte hänsyn till den här målkonflikten: Ytterligare processer kräver också minne. Kontrollera istället om antalet PHP-förfrågningar eller varaktigheten för deras arbetsprocesser kan minskas. Vilken åtgärd som är lämplig beror på var den observerade belastningen uppstår.

En bättre utnyttjad cache kan hantera upprepade förfrågningar, medan snabbare PHP-körning och databasåtkomst frigör arbetare tidigare. Lämpliga bakgrundsuppgifter kan flyttas bort från den direkta förfrågningsvägen; även dessa uppgifter kräver dock egna resurser. En belastningsbegränsning skyddar backend vid toppbelastningar, men kan leda till att förfrågningar får vänta eller avvisas.

Ytterligare RAM-minne kan möjliggöra ett större antal arbetare om minnet faktiskt utgör den avgörande begränsningen. Om CPU:n, databasen eller en extern tjänst redan är fullt utnyttjade måste även deras kapacitet beaktas. Mer minne i sig garanterar därför varken kortare svarstider eller högre genomströmning.

Om lagringsbehovet för enskilda arbetare ökar under deras livslängd kan pm.max_requests se till att de byts ut regelbundet. Detta kan vara till hjälp vid hantering av minnesläckor i tredjepartsbibliotek, men åtgärdar inte orsaken till dem. Fortsätt att övervaka poolminnet och förfrågningsmönstret efter en ändring, istället för att använda omstartsmekanismen som en ersättning för felsökning.

För ett mer övergripande arkitekturval erbjuder Jämförelse mellan NGINX Unit och PHP-FPM Bakgrund: NGINX Unit har arkiverats och underhålls inte längre. Oavsett vilken arkitektur du väljer bör du göra ändringar utifrån tidsserier Kontrollera: Jämför kö, arbetsbelastning, minnesanvändning och svarstider vid liknande förfrågningsvolym. På så sätt kan man se om en justering faktiskt har avhjälpt flaskhalsen eller bara flyttat den.