PHP-FPM-oppsett: bruk pm static for maksimal ytelse

En uredigert versjon av denne artikkelen ble opprinnelig publisert på haydenjames.io og publisert her med hennes tillatelse forfatter.

Jeg skal fortelle deg i et nøtteskall hvordan du best konfigurerer PHP-FPM for å øke gjennomstrømmingen, redusere ventetiden og bruke CPU og minne mer konsekvent. Som standard er PM (prosessleder)-linjen i PHP-FPM dynamisk, og hvis du ikke har nok minne, er det bedre å installere på etterspørsel. La oss sammenligne 2 kontrollalternativer basert på php.net-dokumentasjonen og se hvordan favoritten min skiller seg fra dem statisk pm for mye trafikk:

pm = dynamisk — antall underordnede prosesser er konfigurert dynamisk basert på følgende direktiver: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = etterspørsel - prosesser opprettes på forespørsel (i motsetning til dynamisk opprettelse, når pm.start_servers lanseres når tjenesten starter).
pm = statisk — antall underordnede prosesser er fast og indikeres av parameteren pm.max_barn.

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

Likheter mellom PHP-FPM-prosessbehandleren og CPU-frekvenskontrolleren

Dette kan virke offtopic, men jeg skal koble dette til emnet PHP-FPM-konfigurasjon. Hvem har ikke opplevd en prosessornedgang minst én gang - på en bærbar datamaskin, virtuell maskin eller dedikert server? Husker du CPU-frekvensskalering? Disse alternativene er tilgjengelige for nix og Windows kan forbedre systemytelsen og responsen ved å endre prosessorgassinnstillingen fra på etterspørsel på opptreden*. Denne gangen, la oss sammenligne beskrivelsene og se på likhetene:

guvernør = etterspørsel — dynamisk skalering av prosessorfrekvens avhengig av gjeldende belastning. Hopper raskt til maksimal frekvens og reduserer den etter hvert som perioder med inaktivitet øker.
guvernør=konservativ= dynamisk frekvensskalering avhengig av gjeldende belastning. Øker og reduserer frekvensen jevnere enn på forespørsel.
Sysselmann = ytelse — frekvensen er alltid maksimal.

For detaljer, se fullstendig liste over parametere for prosessorfrekvensregulator.

Ser du likhetene? Jeg ønsket å vise denne sammenligningen for å overbevise deg om at den er best å bruke pm statisk for PHP-FPM.

For prosessorregulatorparameteren ytelse bidrar til å øke ytelsen på en sikker måte fordi den er nesten helt avhengig av serverens CPU-grense. I tillegg til dette kommer det selvfølgelig også faktorer som temperatur, batterilading (i en bærbar PC) og andre bivirkninger av å hele tiden kjøre prosessoren på 100%. Ytelsesinnstillingen sikrer den raskeste prosessorytelsen. Les for eksempel om force_turbo-parameter i Raspberry Pisom RPi-panelet vil bruke regulatoren med ytelse, hvor ytelsesforbedringen vil være mer merkbar på grunn av den lave CPU-klokkehastigheten.

Bruker pm static for å oppnå maksimal serverytelse

PHP-FPM-alternativ pm statisk avhenger i stor grad av ledig minne på serveren. Hvis minnet er lavt, er det bedre å velge på etterspørsel eller dynamisk. På den annen side, hvis du har minne, kan du unngå PHP-prosessbehandlingen ved å sette pm statisk til maksimal serverkapasitet. Med andre ord, hvis alt er beregnet godt, må du etablere pm.statisk til det maksimale volumet av PHP-FPM-prosesser som kan utføres, uten å skape problemer med lite minne eller cache. Men ikke så høyt at det overvelder prosessorene og samler en haug med PHP-FPM-operasjoner som venter på å bli utført.

I skjermbildet ovenfor har serveren pm = statisk og pm.max_children = 100, og dette tar opp omtrent 10 GB av de tilgjengelige 32. Vær oppmerksom på de uthevede kolonnene, alt er klart her. I dette skjermbildet var det omtrent 200 aktive brukere (mer enn 60 sekunder) i Google Analytics. På dette nivået er omtrent 70 % av PHP-FPM underordnede prosesser fortsatt inaktive. Dette betyr at PHP-FPM alltid er satt til maksimal mengde serverressurser uavhengig av gjeldende trafikk. En inaktiv prosess venter på trafikktopper og reagerer umiddelbart. Du trenger ikke vente til pm vil opprette underordnede prosesser og deretter avslutte dem når perioden utløper pm.process_idle_timeout. Jeg satte verdien til veldig høy pm.max_requestsfordi dette er en fungerende server uten minnelekkasjer i PHP. Du kan installere pm.max_requests = 0 med statisk hvis du er helt trygg på eksisterende og fremtidige PHP-skript. Men det er bedre å kjøre skriptene på nytt over tid. Still inn et stort antall forespørsler, fordi vi ønsker å unngå unødvendige pm-kostnader. For eksempel i det minste pm.max_requests = 1000 - avhengig av mengde pm.max_barn og antall forespørsler per sekund.

Skjermbildet viser kommandoen Linux topp, filtrert etter u (bruker) og PHP-FPM brukernavn. Bare de første 50 eller så prosessene vises (jeg regnet ikke nøyaktig), men i hovedsak viser toppen toppstatistikken som passer inn i terminalvinduet. I dette tilfellet sortert etter % CPU (%CPU). For å se alle 100 PHP-FPM-prosesser, kjør kommandoen:

top -bn1 | grep php-fpm

Når du skal bruke pm ondemand og dynamisk

Hvis du bruker pm dynamisk, feil som dette oppstår:

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 å endre parameteren, feilen vil ikke forsvinne, som beskrevet i dette innlegget på Serverfault. I dette tilfellet var pm.min-verdien for liten, og siden netttrafikken varierer så mye og har høye topper og dype daler, er det vanskelig å tilpasse pm. dynamisk. Vanligvis brukes pm på etterspørsel, som anbefalt i samme innlegg. Men dette er enda verre, fordi på etterspørsel avslutter inaktive prosesser til null når det er liten eller ingen trafikk, og du vil fortsatt ende opp med kostnadene ved å endre trafikk. Med mindre du angir en enorm ventetid, selvfølgelig. Og da er det bedre å bruke pm.statisk + høyt tall pm.max_requests.

PM dynamisk og spesielt på etterspørsel kan være nyttig hvis du har flere PHP-FPM-pooler. For eksempel er du vert for flere cPanel-kontoer eller flere nettsteder i forskjellige bassenger. Jeg har en server med for eksempel 100+ cpanel-kontoer og rundt 200 domener, og pm.static eller til og med dynamisk ville ikke redde meg. Alt du trenger her er på etterspørsel, tross alt, mer enn to tredjedeler av nettsteder mottar liten eller ingen trafikk, og med på etterspørsel alle barneprosesser vil falle av, noe som vil spare oss for mye minne! Heldigvis la cPanel-utviklerne merke til dette og satte verdien til standard på etterspørsel. Tidligere, da standard var dynamisk, PHP-FPM var ikke egnet for travle delte servere i det hele tatt. Mange har brukt suPHP, fordi kl dynamisk forbrukt minne selv med inaktive bassenger og cPanel PHP-FPM-kontoer. Mest sannsynlig, hvis trafikken er god, vil du ikke være vert på en server med et stort antall PHP-FPM-pooler (delt hosting).

Konklusjon

Hvis du bruker PHP-FPM og trafikken er stor, kan prosessledere på etterspørsel и dynamisk for PHP-FPM vil være begrenset gjennomstrømning på grunn av deres iboende overhead. Forstå systemet ditt og konfigurer PHP-FPM-prosesser i henhold til maksimal serverkapasitet. Første sett pm.max_barn avhengig av maksimal pm-bruk dynamisk eller på etterspørsel, og øk deretter denne verdien til et nivå der minnet og prosessoren vil fungere uten å bli overbelastet. Det vil du merke med pm statisk, siden du har alt i minnet, vil trafikktopper føre til færre CPU-topper over tid, og server- og CPU-belastningsgjennomsnitt vil jevne seg ut. Den gjennomsnittlige PHP-FPM-prosessstørrelsen avhenger av webserveren og krever manuell konfigurasjon, så mer automatiserte prosessledere er dynamisk и på etterspørsel - mer populær. Jeg håper artikkelen var nyttig.

UPD Lagt til referansediagram ab. Hvis PHP-FPM-prosesser er i minnet, øker ytelsen på bekostning av minneforbruket der de sitter og venter. Finn det beste alternativet for deg selv.

Kilde: www.habr.com