PHP-FPM opsætning: brug pm static for maksimal ydeevne

En uredigeret version af denne artikel blev oprindeligt offentliggjort den haydenjames.io og offentliggjort her med hendes tilladelse forfatter.

Jeg vil fortælle dig i en nøddeskal, hvordan du bedst konfigurerer PHP-FPM til at øge gennemløbet, reducere latency og bruge CPU og hukommelse mere konsekvent. Som standard er PM (proces manager) linjen i PHP-FPM dynamisk, og hvis du ikke har nok hukommelse, så er det bedre at installere efter behov. Lad os sammenligne 2 kontrolmuligheder baseret på php.net-dokumentationen og se, hvordan min favorit adskiller sig fra dem statisk pm for stor trafik:

pm = dynamisk — antallet af underordnede processer er konfigureret dynamisk baseret på følgende direktiver: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = efterspørgsel - processer oprettes efter behov (i modsætning til dynamisk oprettelse, når pm.start_servers lanceres, når tjenesten starter).
pm = statisk — antallet af underordnede processer er fast og er angivet med parameteren pm.max_børn.

For detaljer, se komplet liste over globale direktiver php-fpm.conf.

Ligheder mellem PHP-FPM-procesmanageren og CPU-frekvenscontrolleren

Dette kan virke offtopic, men jeg vil linke dette til emnet PHP-FPM-konfiguration. Hvem har ikke oplevet en processornedgang mindst én gang - på en bærbar computer, virtuel maskine eller dedikeret server. Husker du CPU-frekvensskalering? Disse muligheder er tilgængelige for nix og Windows kan forbedre systemets ydeevne og reaktionsevne ved at ændre processorgasindstillingen fra efter behov på ydeevne*. Lad os denne gang sammenligne beskrivelserne og se på lighederne:

guvernør = efterspørgsel — dynamisk skalering af processorfrekvens afhængig af den aktuelle belastning. Springer hurtigt til maksimal frekvens og reducerer den derefter, efterhånden som perioder med inaktivitet øges.
guvernør=konservativ= dynamisk frekvensskalering afhængig af den aktuelle belastning. Øger og sænker frekvensen mere jævnt end efter behov.
Guvernør = præstation — frekvensen er altid maksimal.

For detaljer, se komplet liste over processorfrekvensregulatorparametre.

Kan du se lighederne? Jeg ville gerne vise denne sammenligning for at overbevise dig om, at den er bedst at bruge pm statisk til PHP-FPM.

For parameteren processorregulator ydeevne hjælper med at øge ydeevnen sikkert, fordi den er næsten helt afhængig af serverens CPU-grænse. Ud over dette er der selvfølgelig også faktorer som temperatur, batteriopladning (i en bærbar) og andre bivirkninger ved konstant at køre processoren på 100%. Ydeevneindstillingen sikrer den hurtigste processorydelse. Læs fx om force_turbo parameter i Raspberry Pi, som RPi-panelet vil bruge regulatoren med ydeevne, hvor ydelsesforbedringen vil være mere mærkbar på grund af den lave CPU-clockhastighed.

Brug af pm static for at opnå maksimal serverydelse

PHP-FPM mulighed pm statisk afhænger i høj grad af den ledige hukommelse på serveren. Hvis hukommelsen er lav, er det bedre at vælge efter behov eller dynamisk. På den anden side, hvis du har hukommelse, kan du undgå PHP-procesmanageren overhead ved at indstille pm statisk til den maksimale serverkapacitet. Med andre ord, hvis alt er beregnet godt, skal du fastslå pm.statisk til det maksimale volumen af ​​PHP-FPM-processer, der kan udføres, uden at skabe problemer med lav hukommelse eller cache. Men ikke så højt, at det overvælder processorerne og akkumulerer en masse PHP-FPM-operationer, der venter på at blive udført.

I skærmbilledet ovenfor har serveren pm = statisk og pm.max_children = 100, og dette fylder cirka 10 GB ud af de tilgængelige 32. Vær opmærksom på de fremhævede kolonner, alt er klart her. I dette skærmbillede var der cirka 200 aktive brugere (mere end 60 sekunder) i Google Analytics. På dette niveau er cirka 70 % af PHP-FPM underordnede processer stadig inaktive. Dette betyder, at PHP-FPM altid er indstillet til den maksimale mængde serverressourcer uanset den aktuelle trafik. En inaktiv proces venter på trafiktop og reagerer øjeblikkeligt. Du behøver ikke vente til pm vil oprette underordnede processer og derefter afslutte dem, når perioden udløber pm.process_idle_timeout. Jeg satte værdien til meget høj pm.max_requestsfordi dette er en fungerende server uden hukommelseslækager i PHP. Du kan installere pm.max_requests = 0 med statisk, hvis du er fuldstændig sikker på eksisterende og fremtidige PHP-scripts. Men det er bedre at køre scripts igen over tid. Indstil et stort antal anmodninger, fordi vi ønsker at undgå unødvendige pm-omkostninger. For eksempel i hvert fald pm.max_requests = 1000 - afhængig af mængde pm.max_børn og antallet af anmodninger pr. sekund.

Skærmbilledet viser kommandoen Linux top, filtreret efter u (bruger) og PHP-FPM brugernavn. Kun de første 50 eller deromkring processer vises (jeg talte ikke nøjagtigt), men i det væsentlige viser toppen den øverste statistik, der passer ind i terminalvinduet. I dette tilfælde sorteret efter % CPU (%CPU). For at se alle 100 PHP-FPM processer skal du køre kommandoen:

top -bn1 | grep php-fpm

Hvornår skal man bruge pm ondemand og dynamisk

Hvis du bruger pm dynamisk, opstår fejl som denne:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Prøv at ændre parameteren, fejlen vil ikke forsvinde, f.eks beskrevet i dette indlæg om Serverfault. I dette tilfælde var pm.min værdien for lille, og da webtrafikken varierer så meget og har høje toppe og dybe dale, er det svært at justere pm tilstrækkeligt dynamisk. Normalt bruges pm efter behov, som anbefalet i samme indlæg. Men dette er endnu værre, fordi efter behov afslutter tomgangsprocesser til nul, når der er lidt eller ingen trafik, og du vil stadig ende op med overhead af skiftende trafik. Medmindre du selvfølgelig angiver en enorm ventetid. Og så er det bedre at bruge pm.statisk + højt tal pm.max_requests.

PM dynamisk og især efter behov kan være praktisk, hvis du har flere PHP-FPM-puljer. For eksempel hoster du flere cPanel-konti eller flere websteder i forskellige puljer. Jeg har en server med f.eks. 100+ cpanel-konti og omkring 200 domæner, og pm.static eller endda dynamisk ville ikke redde mig. Alt du behøver her er efter behov, trods alt, mere end to tredjedele af websteder modtager lidt eller ingen trafik, og med efter behov alle børneprocesser vil falde af, hvilket vil spare os for meget hukommelse! Heldigvis bemærkede cPanel-udviklerne dette og satte værdien til standard efter behov. Tidligere, da standarden var dynamisk, PHP-FPM var slet ikke egnet til travle delte servere. Mange har brugt suPHP, fordi kl dynamisk forbrugt hukommelse selv med inaktive pools og cPanel PHP-FPM-konti. Højst sandsynligt, hvis trafikken er god, vil du ikke blive hostet på en server med et stort antal PHP-FPM-puljer (delt hosting).

Konklusion

Hvis du bruger PHP-FPM, og din trafik er tung, skal du procesledere efter behov и dynamisk for PHP-FPM vil være begrænset gennemstrømning på grund af deres iboende overhead. Forstå dit system og konfigurer PHP-FPM-processer i henhold til den maksimale serverkapacitet. Første sæt pm.max_børn afhængig af maksimalt pm-forbrug dynamisk eller efter behov, og øg derefter denne værdi til et niveau, hvor hukommelsen og processoren fungerer uden at blive overbelastet. Det vil du bemærke med pm statisk, da du har alt i hukommelsen, vil trafikspidser forårsage færre CPU-spidser over tid, og server- og CPU-belastningsgennemsnit vil udjævnes. Den gennemsnitlige PHP-FPM-processtørrelse afhænger af webserveren og kræver manuel konfiguration, så mere automatiserede procesledere er dynamisk и efter behov - mere populær. Jeg håber, at artiklen var nyttig.

DUP Tilføjet benchmark-diagram ab. Hvis PHP-FPM processer er i hukommelsen, øges ydeevnen på bekostning af hukommelsesforbruget, hvor de sidder og venter. Find den bedste mulighed for dig selv.

Kilde: www.habr.com