🥇Opsætning af PHP-FPM: Brug pm static for maksimal ydeevne

Den uredigerede version af artiklen blev oprindeligt offentliggjort på haydenjames.io og offentliggøres her med tilladelse fra forfatter til.

Jeg vil kort forklare, hvordan man bedst konfigurerer PHP-FPM for at øge båndbredden, reducere latenstiden og bruge processorkraft og hukommelse mere stabilt. Som standard er PM (process manager, processtyring) i PHP-FPM indstillet til dynamisk, men hvis du har mangel på hukommelse, er det bedst at sætte det til ondemand. Lad os sammenligne de 2 styringsmetoder baseret på dokumentationen fra php.net og se, hvordan min favorit adskiller sig fra dem static pm til høje trafikmængder:

pm = dynamic — antallet af underordnede processer konfigureres dynamisk baseret på følgende direktiver: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — processer oprettes efter behov (i modsætning til dynamisk oprettelse, hvor pm.start_servers startes ved tjenestens opstart).
pm = static — antallet af underordnede processer er fast og angives ved parameteren pm.max_children.

Se detaljer i en komplet liste over globale direktiver php-fpm.conf.

Lighederne mellem PHP-FPMs processtyrer og procesfrekvensregulatoren

Det kan virke off-topic, men jeg vil forbinde det med emnet for konfiguration af PHP-FPM. Hvem har ikke oplevet, at processoren hænger — på en bærbar computer, virtuel maskine eller dedikeret server. Kan du huske skalering af procesfrekvensen? Disse parametre, der er tilgængelige for nix og Windows, kan forbedre ydeevnen og systemets responstid, hvis du ændrer procesfrekvensregulatorparameteren til ondemand og få en fungerende kommando. performance*. Denne gang lad os sammenligne beskrivelserne og se lighederne:

Governor = ondemand — dynamisk skalering af procesfrekvens afhængigt af den aktuelle belastning. Skifter hurtigt til maksimal frekvens og sænker den derefter, når der er længere perioder med inaktivitet.
Governor = conservative = dynamisk skalering af frekvens afhængigt af den aktuelle belastning. Øger og reducerer frekvensen mere blødt end ondemand.
Governor = performance — frekvensen er altid maksimal.

Se detaljer i en komplet liste over parametre for procesfrekvensregulatoren.

Ser du ligheden? Jeg ville vise denne sammenligning for at overbevise dig om, at det bedst kan betale sig at bruge pm static til PHP-FPM.

For procesfrekvensregulatoren er parameteren performance hjælper med at øge ydeevnen sikkert, da det næsten helt afhænger af serverens CPU-grænse. Derudover er der selvfølgelig også andre faktorer som temperatur, batteriniveau (i en bærbar) og andre bivirkninger ved konstant at køre CPU'en på 100%. Performance-indstillingen sikrer den hurtigste drift af CPU'en. Læs f.eks. om parameteret force_turbo i Raspberry Pi, som RPi-panelet vil anvende til regulering performance, hvor forbedringen af ydeevnen vil være mere mærkbar på grund af den lave CPU-clockfrekvens.

Brug af pm static for at opnå maksimal serverydelse

PHP-FPM parameteren pm static afhænger i høj grad af den ledige hukommelse på serveren. Hvis der er lidt hukommelse, er det bedre at vælge ondemand eller dynamisk. På den anden side, hvis du har hukommelse, kan du undgå unødvendige omkostninger ved PHP-procesmanageren ved at indstille pm static til serverens maksimale kapacitet. Med andre ord, hvis alt regnes godt, skal du indstille pm.static til det maksimale antal PHP-FPM-processer, der kan køre, uden at skabe problemer med mangel på hukommelse eller cache. Men ikke så højt, at det overbelaster CPU'erne og skaber en bunke afventende PHP-FPM-operationer.

På skærmbilledet ovenfor er der indstillet pm = static og pm.max_children = 100, og det bruger cirka 10 GB af de tilgængelige 32. Bemærk de fremhævede kolonner, alt er klart her. På 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-børn stadig inaktive. Dette betyder, at PHP-FPM altid er indstillet til maksimalt at udnytte serverressourcerne uanset den nuværende trafik. Den inaktive proces venter på trafikspidser og reagerer øjeblikkeligt. Du skal ikke vente, indtil pm opretter børneprocesser, og derefter afslutter dem, når perioden pm.process_idle_timeoutudløber. Jeg har indstillet en meget høj værdi for pm.max_requests, fordi det er en arbejdsserver uden hukommelseslækager i PHP. Du kan indstille pm.max_requests = 0 med static, hvis du er helt sikker på de nuværende og fremtidige PHP-scripts. Men det er bedre at genstarte scripts over tid. Indstil et højt antal forespørgsler, for vi vil undgå unødvendige pm-omkostninger. For eksempel mindst pm.max_requests = 1000 — afhængigt af antallet pm.max_children og antallet af forespørgsler pr. sekund.

Skærmbilledet viser kommandoen Linux top, filtreret efter u (bruger) og brugernavn PHP-FPM. Viser kun de første 50 eller deromkring processer (har ikke talt dem præcist), men grundlæggende viser top topstatistikken, der placeres i terminalvinduet. I dette tilfælde med sortering efter % CPU (%CPU). For at se alle 100 processer PHP-FPM, skal du køre kommandoen:

top -bn1 | grep php-fpm

Hvornår man skal bruge pm ondemand og dynamic

Hvis man bruger pm dynamisk, opstår der lignende fejl:

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 forsvinder ikke, som beskrevet i dette indlæg på Serverfault. I dette tilfælde var værdien pm.min for lille, og da webtrafikken ændrer sig meget, og der er høje toppe og dybe fald, er det svært at konfigurere pm passende. dynamisk. Normalt anvendes pm ondemand, som anbefalet i det samme indlæg. Men det er endnu værre, for ondemand afslutter inaktive processer til nul, når der er lidt eller ingen trafik, og i sidste ende vil du stadig lide under omkostningerne ved ændringer i trafikken. Medmindre du selvfølgelig har indstillet en meget høj ventetid. Og så er det bedre at bruge pm.static + et højt tal pm.max_requests.

PM dynamisk og især ondemand kan være nyttige, hvis du har flere PHP-FPM-pooler. For eksempel, hvis du hoster flere cPanel-konti eller flere hjemmesider i forskellige pools. Jeg har en server, hvor der eksempelvis er 100+ cPanel-konti og cirka 200 domæner, og pm.static eller endda dynamic ville ikke redde mig. Her kræves kun ondemand, for mere end to tredjedele af hjemmesiderne får lidt eller slet ingen trafik, og med ondemand vil alle underprocesserne falde, hvilket sparer os en masse hukommelse! Heldigvis bemærkede udviklerne af cPanel dette og indstillede standardværdien ondemand. Tidligere, da standardværdien var dynamisk, var PHP-FPM overhovedet ikke egnet til belastede delte servere. Mange brugte suPHP, fordi pm dynamisk forbrugte hukommelse selv ved inaktive pools og cPanel-konti PHP-FPM. Sandsynligvis, ved en god trafik, vil du ikke blive hostet på en server med et stort antal PHP-FPM-pooler (delt hosting).

Konklusion

Hvis du bruger PHP-FPM og har seriøs trafik, vil processtyringsværktøjerne ondemand og dynamisk for PHP-FPM begrænse kapaciteten på grund af de iboende omkostninger. Undersøg dit system og konfigurer PHP-FPM-processerne i forhold til serverens maksimale kapacitet. Start med at angive pm.max_children afhængigt af den maksimale brug af pm dynamisk eller ondemand, og derefter øg denne værdi til det niveau, hvor hukommelsen og processoren fungerer uden overbelastning. Du vil bemærke, at med pm static, eftersom alt er lagret i hukommelsen, vil trafiktoppe over tid forårsage færre toppe for processoren, og gennemsnitsbelastningen for server og processor vil stabilisere sig. Den gennemsnitlige størrelse på PHP-FPM-processen afhænger af webserveren og kræver manuel konfiguration, derfor er mere automatiserede procesadministratorer — dynamisk og ondemand — mere populære. Jeg håber, at artiklen var nyttig.

UPD Diagrammet for benchmark er blevet tilføjet ab. Hvis PHP-FPM-processerne er i hukommelsen, øges ydeevnen ved at forbruge hukommelse, hvor de sidder og venter. Find den optimale løsning for dig.