De onbewerkte versie van dit artikel is oorspronkelijk gepubliceerd op en wordt hier gepubliceerd met toestemming van .
Ik zal in het kort uitleggen hoe je PHP-FPM het beste kunt configureren om de doorvoer te verhogen, de latentie te verlagen en de CPU- en geheugengebruik stabiler te maken. Standaard heeft de PM (process manager, procesbeheerder) in PHP-FPM de waarde dynamic, maar als je niet genoeg geheugen hebt, is het beter om in te stellen op ondemand. Laten we de 2 beheermethoden vergelijken op basis van de documentatie van php.net en kijken hoe mijn favoriete static pm zich verhoudt tot een hoog verkeer:
pm = dynamic — het aantal kindprocessen wordt dynamisch ingesteld op basis van de volgende richtlijnen: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — processen worden op aanvraag gemaakt (in tegenstelling tot dynamische creatie, waarbij pm.start_servers wordt gestart bij het opstarten van de dienst).
pm = static — het aantal kindprocessen is vast en wordt ingesteld met de parameter pm.max_children.
Zie voor details .
Overeenkomsten tussen de PHP-FPM procesmanager en de CPU frequentie-onderregelaar
Dit lijkt misschien off-topic, maar ik ga dit verbinden met het onderwerp van de configuratie van PHP-FPM. Wie heeft er niet eens een trage CPU gehad — op een laptop, virtuele machine of dedicated server. Herinnert u zich de schaling van de CPU-frequency? Deze instelling, beschikbaar voor nix en Windows, kan de prestaties en de reactietijd van het systeem verbeteren door de CPU-regelaar parameter te veranderen van ondemand en een werkende opdracht krijgen. performance*. Laten we deze keer de beschrijvingen vergelijken en de overeenkomsten bekijken:
Governor = ondemand — dynamische schaling van de CPU-frequentie op basis van de huidige belasting. Schakelt snel naar de maximale frequentie en verlaagt deze vervolgens wanneer de periodes van inactiviteit toenemen.
Governor = conservative = dynamische schaling van de frequentie afhankelijk van de huidige belasting. Verhoogt en verlaagt de frequentie geleidelijker dan ondemand.
Governor = performance — de frequentie is altijd maximaal.
Zie voor details .
Zie je de overeenkomst? Ik wilde deze vergelijking maken om je te overtuigen dat het het beste is om pm static voor PHP-FPM te gebruiken.
Voor de CPU-regelaar is de parameter performance helpt veilig de prestaties te verhogen, omdat dit vrijwel volledig afhangt van de CPU-limiet van de server. Daarnaast zijn er natuurlijk nog andere factoren, zoals temperatuur, batterijduur (in een laptop) en andere bijwerkingen van het blijven werken van de CPU op 100%. De performance-instelling zorgt voor de snelste werking van de CPU. Lees bijvoorbeeld over , waarmee het RPi-paneel de regulator zal gebruiken performance, waarbij de prestatieverbetering merkbaarder zal zijn door de lage kloksnelheid van de CPU.
Het gebruik van pm static om maximale serverprestaties te bereiken
De PHP-FPM-parameter pm static is sterk afhankelijk van het beschikbare geheugen op de server. Als er weinig geheugen beschikbaar is, is het beter om ondemand of dynamic. Aan de andere kant, als je voldoende geheugen hebt, kun je onnodige kosten voor de PHP-processorenmanager vermijden door pm static op de maximale capaciteit van de server in te stellen. Met andere woorden, als het goed wordt berekend, moet je pm.static instellen op het maximale aantal PHP-FPM-processen dat kan draaien, zonder problemen met geheugen- of cache-tekort te veroorzaken. Maar niet zo hoog dat het de processoren overbelast en een stapel PHP-FPM-operaties accumuleert die wachten op uitvoering..
In de screenshot hierboven is de server ingesteld op pm = static en pm.max_children = 100, en dat neemt ongeveer 10 GB in beslag van de beschikbare 32. Let op de gemarkeerde kolommen, het is daar duidelijk. In deze screenshot waren er ongeveer 200 actieve gebruikers (meer dan 60 seconden) in Google Analytics. Op dit niveau is ongeveer 70% van de kindprocessen van PHP-FPM nog steeds inactief. Dit betekent dat PHP-FPM altijd is ingesteld op het maximale aantal beschikbare serverresources, ongeacht het huidige verkeer. Een inactief proces wacht op verkeerspieken en reageert onmiddellijk. Je hoeft niet te wachten tot pm kindprocessen aanmaakt, en daarna deze beëindigt wanneer de periode verstrijkt pm.process_idle_timeout. Ik heb een zeer grote waarde ingesteld voor pm.max_requests, omdat dit een werkserver is zonder geheugenlekken in PHP. Je kunt pm.max_requests = 0 instellen met static, als je volledig zeker bent van de bestaande en toekomstige PHP-scripts. Maar het is beter om de scripts na verloop van tijd opnieuw te starten. Stel een groot aantal aanvragen in, want we willen onnodige kosten voor pm vermijden. Bijvoorbeeld minstens pm.max_requests = 1000 — afhankelijk van het aantal pm.max_children en het aantal aanvragen per seconde.
In de screenshot is het commando weergegeven , gefilterd op u (gebruiker) en gebruikersnaam PHP-FPM. Toont alleen de eerste 50 processen of ongeveer dat aantal (niet precies geteld), maar in wezen toont top de topstatistieken die in het terminalvenster passen. In dit geval met sortering op % CPU (%CPU). Om alle 100 PHP-FPM-processen te bekijken, voert u de volgende opdracht uit:
top -bn1 | grep php-fpmWanneer pm ondemand en dynamic te gebruiken
Als u pm gebruikt dynamic, ontstaan dergelijke fouten:
WARNING: [pool xxxx] lijkt druk (u moet misschien pm.start_servers, of pm.min/max_spare_servers verhogen), het spawn van 32 kinderen, er zijn 4 inactief, en 59 totaal kinderenProbeer de parameter te wijzigen, de fout verdwijnt niet, zoals . In dit geval was de waarde van pm.min te laag, en omdat het webverkeer sterk verandert met hoge pieken en diepe dalen, is het moeilijk om pm adequaat af te stemmen dynamic. Gewoonlijk wordt pm gebruikt ondemand, . Maar dat is nog erger, want ondemand beëindigt inactieve processen tot nul, wanneer er weinig of helemaal geen verkeer is, en uiteindelijk zult u ook te maken krijgen met kosten bij verkeersschommelingen. Tenminste, tenzij u een enorme wachttijd hebt ingesteld. En dan kunt u beter pm.static + een hoog aantal pm.max_requests.
PM dynamic en vooral ondemand kunnen nuttig zijn, als u meerdere PHP-FPM-pools heeft. Bijvoorbeeld, als u meerdere cPanel-accounts of meerdere websites in verschillende pools host. Ik heb een server waar, laten we zeggen, 100+ cPanel-accounts en ongeveer 200 domeinen zijn, en pm.static of zelfs dynamic zou me niet redden. Hier heeft u alleen maar ondemand, want meer dan twee derden van de websites ontvangt weinig of helemaal geen verkeer, en met ondemand vallen alle kindprocessen weg, wat ons veel geheugen bespaart! Gelukkig hebben de ontwikkelaars van cPanel dit opgemerkt en hebben ze de standaardwaarde ingesteld ondemand. Eerder, toen de standaardwaarde was dynamic, was PHP-FPM helemaal niet geschikt voor drukbevolkte gedeelde servers. Velen gebruikten suPHP, omdat pm dynamic geheugen verbruikte, zelfs bij inactieve pools en cPanel-accounts PHP-FPM. Waarschijnlijk zult u bij goed verkeer niet op een server worden gehost met veel PHP-FPM-pools (shared hosting).
Conclusie
Als u PHP-FPM gebruikt en uw verkeer is serieus, zullen procesbeheerders ondemand en dynamic voor PHP-FPM de bandbreedte beperken vanwege de inherente kosten. Bestudeer uw systeem en configureer de PHP-FPM-processen volgens de maximale capaciteit van de server. Stel eerst in pm.max_children afhankelijk van het maximale gebruik van pm dynamic of ondemand, en verhoog deze waarde vervolgens naar het niveau waarop geheugen en processor zonder overbelasting werken. U zult merken dat met pm static, omdat alles in het geheugen is opgeslagen, pieken in het verkeer na verloop van tijd minder pieken voor de processor zullen veroorzaken, terwijl de gemiddelde server- en processorbelasting gelijkmatiger zal worden. De gemiddelde grootte van het PHP-FPM-proces hangt af van de webserver en vereist handmatige configuratie, daarom zijn meer geautomatiseerde procesbeheerders — dynamic en ondemand — populairder. Ik hoop dat het artikel nuttig was.
UPD Benchmarkdiagram toegevoegd . Als PHP-FPM-processen in het geheugen staan, verbetert de prestaties door het geheugengebruik, waar ze zitten en wachten. Vind de optimale optie voor uzelf.
Bron: habr.com
