Kapacitetsplanlægning for PHP-FPM: Beregning af worker-instanser, RAM og samtidige anmodninger

Hvad der begrænser en PHP-FPM-worker

PHP-FPM administrerer PHP-processer i puljer. En Arbejder behandler én forespørgsel ad gangen; pool-indstillingen pm.max_children begrænser antallet af arbejdsprocesser, der er tilgængelige på samme tid, og dermed antallet af PHP-forespørgsler, der behandles samtidigt i denne pulje. Hvis der er flere puljer, gælder begrænsningen for den pågældende pulje og ikke automatisk for hele serveren.

Dette tal er hverken antallet af loggede besøgende eller et direkte tal for anmodninger pr. sekund. En besøgende kan udløse flere anmodninger, mens en logget bruger ikke optager en worker mellem to handlinger. Omvendt kan en enkelt langsom anmodning optage en worker i længere tid end flere korte anmodninger i træk.

Det er heller ikke alle sidevisninger, der når frem til PHP-FPM. Hvis webserveren leverer en statisk fil direkte, eller hvis en forudgående cache besvarer en forespørgsel fuldstændigt, er der – afhængigt af arkitekturen – ikke behov for en PHP-worker. Cache-fejl, indloggede brugere og administrationssider kan derimod stadig generere PHP-anmodninger og midlertidigt øge belastningen.

I forbindelse med kapacitetsplanlægningen er der derfor to separate spørgsmål, der er afgørende: Hvor mange arbejdere kan der, med en reserve, være plads til i den tilgængelige RAM? Og hvor mange arbejdere kræver den trafik, der rent faktisk ankommer til puljen, for at forespørgslerne ikke skal vente unødigt længe? En høj værdi for pm.max_children besvarer ikke noget af disse spørgsmål alene.

Selv hvis der er tilstrækkelig lagerplads til rådighed, kan CPU’en, databasen eller eksterne tjenester begrænse den faktiske kapacitet. Yderligere workere muliggør ganske vist mere parallel PHP-behandling, men kan samtidig øge presset på en tjeneste, der i forvejen er langsom. Pool-værdien er derfor en driftsgrænse og ikke en ydelsesgaranti.

Forståelse af proceshåndtering og køer

Der Procesleder fastlægger, hvornår PHP-FPM stiller arbejdsprocesser til rådighed. Ved static svarer det angivne procesnummer til værdien af pm.max_children. Det gør det nemt at planlægge antallet af processer, men binder også ressourcer, selv når udnyttelsesgraden er lav. Selve den øvre grænse skal fortsat passe til den tilgængelige lagerplads.

Med dynamic justerer FPM antallet af processer: Startantal samt minimalt og maksimalt antal ledige arbejdere indstilles desuden. Ved ondemand Workere oprettes først efter behov og afsluttes efter en konfigureret inaktivitetstid. Dette kan spare ressourcer i puljer, der sjældent bruges; ved en pludselig belastningsspids skal der dog først oprettes ny proceskapacitet.

Hvis alle arbejdere er beskæftiget, kan yderligere anmodninger i Lytterkø vente på en ledig proces. FPM-statusen viser blandt andet den aktuelle og den maksimale kø. En enkelt høj maksimumsværdi siger dog ikke noget om, hvorvidt puljen lige nu er overbelastet; til det er det nødvendigt med en tidsmæssig sammenhæng.

En større kø skaber ikke flere arbejdsprocesser og gør ikke en langsom database hurtigere. Den kan midlertidigt opfange forespørgsler, men flytter blot ventetiden frem til før PHP-behandlingen. Når man skal vælge procesmanager, er det derfor vigtigt at tage højde for både det typiske belastningsforløb og konsekvenserne af korte spidsbelastninger.

Korrekt klassificering af arbejdshukommelse

En workers hukommelsesbehov kan ikke pålideligt udledes alene ud fra en PHP-konfigurationsgrænse. Processdata under relevante belastningsforhold er mere nyttige til planlægningen. Her gør det en forskel, om du ser på den enkelte process’ residente hukommelse, eller om du vil vurdere forbruget for en hel gruppe af PHP-FPM-workers.

RSS beskriver en process' residente hukommelse. Hvis flere arbejdsprocesser bruger de samme hukommelsessider, kan disse indgå i deres respektive RSS. Hvis man lægger RSS-værdierne for alle arbejdsprocesser sammen, kan fællesbrugte sider under visse omstændigheder optræde flere gange; summen giver derfor ikke et præcist billede af den fysisk hukommelse, der deles.

PSS fordeler fælles sider proportionalt mellem de involverede processer. Summen af PSS-værdierne for en procesgruppe er derfor ofte mere nyttig til planlægning af hukommelsen end summen af RSS-værdierne. Den er dog stadig kun et øjebliksbillede: Hvis antallet af processer, der deler siderne, ændrer sig, ændrer de respektive andele sig også.

Se på flere arbejdere ved typiske og også ved hukommelseskrævende anmodninger. En nystartet proces eller et enkelt gennemsnit kan undervurdere det senere behov. Den samlede pool-PSS ved forskellige antal arbejdsprocesser og belastningstilstande hjælper med at udlede et konservativt skøn; en ekstrapolering til flere arbejdsprocesser er usikker på grund af varierende fælles og private andele.

PHP-memory_limit er ikke et pålideligt tal for den samlede operativsystemhukommelse i en FPM-proces og erstatter ikke denne observation. Fælles hukommelse, f.eks. via OPcache, bør du ikke generelt trække fra budgettet en anden gang, hvis den allerede er medregnet forholdsmæssigt i den anvendte pool-PSS. Andre tjenester og en reserve skal dog stadig tages i betragtning.

Beregne RAM-budget og antal arbejdere

Udgangspunktet er den faktisk tilgængelige RAM: på en host er det den hukommelse, der kan bruges til tjenesterne, i containeren er det den effektive hukommelsesgrænse. Træk herfra behovet for operativsystemet, webserveren, en eventuel lokal database og andre tjenester. Andre FPM-puljer og en reserve til svingende forbrug skal ligeledes medregnes.

Den resterende andel er Poolbudget. For at estimere antallet af arbejdere skal du observere PSS-summen for pool-arbejderne ved forskellige procesantal og belastningstilstande. Tag højde for både typiske forespørgsler og hukommelseskrævende slutpunkter. Del den respektive sum med det betragtede antal arbejdere, og udled en forsigtig tilnærmelsesværdi ud fra flere observationer.

Følgende beregning er et illustrativt eksempel og ikke en måling. De anvendte værdier tjener udelukkende til at vise beregningsmetoden; de udgør ikke en anbefaling til en bestemt anvendelse. Resultatet afrundes til et helt antal arbejdere.

De 25 arbejdere er ikke en garanti for sikker tildeling. PSS fordeler de fælles sider forholdsmæssigt, og fordelingen ændrer sig i takt med antallet af processer, der deler disse sider. Også en anden sammensætning af anmodninger kan påvirke behovet for privat hukommelse; estimatet bør derfor sammenlignes med det observerede samlede forbrug og den gældende grænse.

Hvis delt hukommelse som f.eks. OPcache allerede er medregnet forholdsmæssigt i den anvendte PSS-sum, skal du ikke trække den fra endnu en gang som en samlet ekstra post. Du bør dog alligevel afsætte en reserve til de hukommelsesandele, som din beregning ikke omfatter. Især ved en containergrænse er det i sidste ende forbruget af alle processer inden for grænsen, der tæller, ikke kun den anslåede sum af arbejdsprocesser.

En nyligt startet worker alene er ikke særlig sigende som grundlag: Den har muligvis endnu ikke behandlet en krævende anmodning. Sammenlign derfor flere tidspunkter, og noter, hvilke slutpunkter og hvor mange arbejdere der var involveret i hvert tilfælde. På den måde kan man se, om den valgte tilnærmelsesværdi også holder stik under mindre gunstige, men realistiske driftsforhold.

Vurdere behovet for arbejdere ud fra anmodninger

RAM-beregningen beskriver, hvor mange arbejdere der forventes at være plads til. Behovet afhænger derimod af, hvor mange PHP-anmodninger der faktisk ankommer til den pågældende pool, og hvor længe de optager en worker. Som en første tilnærmelse gælder: det gennemsnitlige antal samtidigt optagede workers er lig med antallet af PHP-anmodninger pr. sekund ganget med den gennemsnitlige worker-optagelsestid i sekunder.

Illustrativt regneeksempel, ikke en måling: Hvis man antager 20 PHP-anmodninger pr. sekund og en gennemsnitlig behandlingstid på 0,25 sekunder, er der i gennemsnit fem arbejdere i gang. Dette er et gennemsnit for den betragtede periode. Det betyder hverken, at der altid er præcis fem processer i gang, eller at fem er tilstrækkeligt som poolgrænse ved korte spidsbelastninger.

Du skal ikke medregne alle sidevisninger uden nærmere kontrol i antallet af forespørgsler. Hvis en cache leverer mange svar uden at kalde PHP, belaster disse hits ikke puljen. Omvendt kan cache-misser, indloggede besøgende og administrative adgangsforespørgsler til tider udløse mere PHP-arbejde, end et gennemsnit over hele dagen antyder.

Die Arbejdstid for arbejdstagere omfatter også ventetider under behandlingen, f.eks. på en database eller en ekstern tjeneste. Den kan ikke automatisk sidestilles med den responstid, der vises i browseren. Ifølge fastcgi_finish_request() PHP kan allerede have afsluttet svaret til klienten og alligevel fortsætte med at udføre arbejde i workeren.

For at opnå acceptable ventetider skal du have et spillerum ud over den gennemsnitlige udnyttelsesgrad. Hvor stort dette spillerum skal være, afhænger blandt andet af belastningsudsving, langsomme slutpunkter og det ønskede svarstidsmål. En multiplikation af spidsbelastningsanmodninger pr. sekund med en høj latenstidsprocentil kan være en forsigtig scenarieanalyse, men er ikke en præcis køprognose.

Man bør derfor betragte flere tidsperioder hver for sig: En kort spidsbelastning og en rolig nattrafik kan give det samme daglige gennemsnit som en mere jævn drift, men stiller forskellige krav. Hvis ventetiden stiger på grund af et langsomt backend, stiger det gennemsnitlige antal bundne medarbejdere også ved samme ankomstfrekvens. Behovet afhænger således ikke udelukkende af besøgsantallet.

Udled poolindstillinger fra planlægningen

Sammenlign nu den RAM-baserede øvre grænse med det anslåede behov, inklusive et sikkerhedsmargen. Hvis behovet ligger under denne grænse, skal du vælge en forsigtig startværdi for pm.max_children, som ikke behøver at udnytte hele budgettet. I det illustrative eksempel ville 25 være den beregnede RAM-grænse, men ikke nødvendigvis den rette indstilling; CPU og backend kan allerede sætte en grænse før det.

Hvis det anslåede behov overstiger RAM-grænsen, løser en højere grænse ikke problemet: Det kan sætte værten eller containeren under pres med hensyn til hukommelse. Omvendt kan en meget lav grænse medføre, at anmodninger må vente. I dette tilfælde bør du f.eks. forbedre eksekveringstiden eller cache-udnyttelsen og undersøge, om der er behov for yderligere ressourcer eller en begrænsning af indgående belastning.

Med dynamisk Her angiver du ud over den øvre grænse også startantalet samt minimums- og maksimumsantalet af ledige arbejdere. Start- og reserveværdierne bør passe til den forventede belastning og holde sig inden for den øvre grænse. For lidt reserveret kapacitet kan ved pludselig belastning medføre et ekstra behov for opstart; derimod forbruger mange ledige processer ressourcer på lang sigt.

Med ondemand Workere oprettes først efter behov; inaktivitetstiden indtil deres afslutning indstilles separat. Dette kan være hensigtsmæssigt for puljer, der sjældent bruges, men kræver særlig opmærksomhed ved hurtige stigninger i belastningen. Også her begrænser pm.max_children antallet af arbejdere i puljen, der er tilgængelige på samme tid.

Flere websteder på samme host får ikke hver især den samlede ledige RAM uafhængigt af hinanden. Planlæg deres mulige pool-maksimum sammen med de øvrige tjenester og reserven. En eventuelt konfigureret global FPM-procesgrænse kan desuden træde i kraft, men erstatter hverken de enkelte pool-budgetter eller kontrollen af CPU- og databasekapaciteten.

Efter ændringer bør du kontrollere den faktiske udnyttelsesgrad og ventetiderne over passende tidsperioder, i stedet for at betragte startværdien som endelig. Ved managed hosting er procesdata eller poolindstillinger muligvis ikke direkte tilgængelige; brug i så fald udbyderens målinger og tilgængelige indstillinger. Hvilke indstillinger der er tilgængelige, afhænger desuden af PHP-versionen og driftsmiljøet.

Overvågning af FPM-status og lagerplads

FPM-statussiden viser, om de planlagte workere er tilstrækkelige under reel belastning. Beskyt statusendepunktet for offentlig adgang: Den kan afsløre følsomme oplysninger om forespørgsler og ressourcer. En separat konfigureret status-listener kan forblive tilgængelig, selv når hovedpuljen er overbelastet; kontroller dens tilgængelighed og opsætning for din PHP-version og webserverkonfiguration.

Betragt værdierne som tidsrækker sammen med forespørgselsvolumen og svartider. En gammel maksimumværdi for køen er ikke et tegn på en aktuel overbelastning; ligeledes er stigningen i tællere siden den sidste observation mere sigende end den rene samlede værdi. Tag i den forbindelse højde for poolstart eller genstarter, som ændrer referenceperioden.

For en kendt FPM-worker kan du på et Linux-system med en tilgængelig proc-grænseflade hente aggregerede hukommelsesværdier i læsemodus. Erstat PID ved hjælp af den faktiske proces-ID; du skal have de nødvendige adgangsrettigheder. Gentag observationen for flere arbejdsprocesser og belastningstilstande, i stedet for at udlede en fast poolstørrelse ud fra en enkelt proces.

cat /proc/PID/smaps_rollup

Undersøgelse af langsomme anmodninger og køer

En webshop kan vise mange aktive arbejdsprocesser, selvom det ikke er selve PHP-udførelsen, der udgør den oprindelige flaskehals. Hvis anmodninger venter på langsomme databaseforespørgsler, forbliver arbejdsprocesserne bundet i mellemtiden. Hvis der kommer flere anmodninger ind, kan lytterkøen vokse, og svartiden stige, selvom CPU'en stadig har ledig kapacitet.

En højere grænse for antallet af arbejdere kan i denne situation muligvis medføre, at flere forespørgsler samtidig når frem til databasen. Det kan Backend-udskrivning og forlænge ventetiderne yderligere. Sammenlign derfor udviklingen over tid i FPM-udnyttelsen og køen med databasebelastningen, langsomme forespørgsler og eksterne tjenesteopkald, inden du hæver grænsen.

FPM-Slowlog hjælper med at indkredse lange PHP-kald: For forespørgsler, der overskrider en konfigureret tærskel, kan FPM logge et backtrace. Dette viser et udførelsespunkt og er ikke en fuldstændig profil af hele forespørgslen. Gentagne steder kan sammenholdes med forespørgselens varighed og backend-metrikker; de Vejledning i analyse af PHP-FPM-slowloggen forklares nærmere i den videre analyse.

Også en timeout skal adskilles fra den egentlige kapacitet. I nginx betegner fastcgi_read_timeout det tilladte interval mellem på hinanden følgende læseoperationer fra FastCGI-serveren, ikke den samlede anmodningsvarighed generelt. En højere værdi kan tillade længere ventetid, men skaber hverken yderligere arbejdsprocesser eller fremskynder databasen.

Kapacitetsgrænser og næste skridt

Hvis RAM-budgettet ikke er tilstrækkeligt til det anslåede behov, løser en højere indstilling for pm.max_children Undgå ikke denne konflikt: Yderligere processer kræver også hukommelse. Undersøg i stedet, om antallet af PHP-forespørgsler eller varigheden af deres worker-belægning kan reduceres. Hvilken foranstaltning der er hensigtsmæssig, afhænger af, hvor den observerede belastning opstår.

En bedre udnyttet cache kan håndtere gentagne anmodninger, mens hurtigere PHP-udførelse og databaseadgang frigiver arbejdsprocesser tidligere. Egnede baggrundsopgaver kan flyttes ud af den umiddelbare anmodningssti; dog kræver også disse opgaver egne ressourcer. En belastningsbegrænsning beskytter backend ved spidsbelastninger, men kan medføre, at anmodninger må vente eller afvises.

Ekstra RAM kan muliggøre et højere antal arbejdsprocesser, hvis hukommelsen rent faktisk udgør den afgørende begrænsning. Hvis CPU’en, databasen eller en ekstern tjeneste allerede er fuldt udnyttet, skal der også tages højde for deres kapacitet. Mere hukommelse alene garanterer derfor hverken kortere svartider eller en højere gennemstrømning.

Hvis de enkelte workeres hukommelsesbehov stiger i løbet af deres levetid, kan pm.max_requests sørge for, at de udskiftes regelmæssigt. Det kan hjælpe med at håndtere hukommelseslækager i tredjepartsbiblioteker, men løser ikke årsagen til dem. Fortsæt med at overvåge poolhukommelsen og forespørgselsmønstrene efter en ændring, i stedet for at bruge genstartmekanismen som erstatning for fejlfinding.

For en mere overordnet arkitekturbeslutning tilbyder Sammenligning af NGINX Unit og PHP-FPM Baggrund: NGINX Unit er arkiveret og vedligeholdes ikke længere. Uanset hvilken arkitektur du vælger, bør du foretage ændringer på baggrund af tidsrækker Kontroller: Sammenlign køen, worker-udnyttelsen, hukommelsen og svartiderne ved et lignende forespørgselsvolumen. På den måde kan man se, om en justering rent faktisk har afhjulpet flaskehalsen eller blot flyttet den.