PHP-FPM-installatie: gebruik pm static voor maximale prestaties

Een onbewerkte versie van dit artikel is oorspronkelijk gepubliceerd op haydenjames.io en hier gepubliceerd met haar toestemming auteur.

Ik zal je in een notendop vertellen hoe je PHP-FPM het beste kunt configureren om de doorvoer te verhogen, de latentie te verminderen en CPU en geheugen consistenter te gebruiken. Standaard is de PM-regel (procesmanager) in PHP-FPM dynamisch, en als je niet genoeg geheugen hebt, is het beter om te installeren op aanvraag. Laten we twee besturingsopties vergelijken op basis van de php.net-documentatie en zien hoe mijn favoriet daarvan verschilt statisch pm voor groot verkeer:

pm = dynamisch — het aantal onderliggende processen wordt dynamisch geconfigureerd op basis van de volgende richtlijnen: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = op aanvraag - processen worden op aanvraag gemaakt (in tegenstelling tot dynamische creatie, wanneer pm.start_servers worden gestart wanneer de service start).
pm = statisch — het aantal onderliggende processen staat vast en wordt aangegeven door de parameter pm.max_kinderen.

Voor details, zie volledige lijst met globale richtlijnen php-fpm.conf.

Overeenkomsten tussen de PHP-FPM-procesmanager en de CPU-frequentiecontroller

Dit lijkt misschien offtopic, maar ik ga dit koppelen aan het onderwerp PHP-FPM-configuratie. Wie heeft niet minstens één keer een processorvertraging ervaren: op een laptop, virtuele machine of dedicated server? Onthoud de CPU-frequentieschaling? Deze opties zijn beschikbaar voor nix en Windows kunnen de systeemprestaties en het reactievermogen verbeteren door de snelheidsinstelling van de processor te wijzigen van op aanvraag op prestatie*. Laten we deze keer de beschrijvingen vergelijken en naar de overeenkomsten kijken:

gouverneur=op aanvraag — dynamische schaling van de processorfrequentie afhankelijk van de huidige belasting. Springt snel naar de maximale frequentie en verlaagt deze vervolgens naarmate de periodes van inactiviteit toenemen.
gouverneur=conservatief= dynamische frequentieschaling afhankelijk van de huidige belasting. Verhoogt en verlaagt de frequentie soepeler dan on-demand.
Gouverneur = prestatie — frequentie is altijd maximaal.

Voor details, zie volledige lijst met processorfrequentieregelaarparameters.

Zie je de overeenkomsten? Ik wilde deze vergelijking laten zien om je ervan te overtuigen dat je deze het beste kunt gebruiken pm statisch voor PHP-FPM.

Voor de processorregelaarparameter prestatie helpt de prestaties veilig te verhogen, omdat deze vrijwel volledig afhankelijk zijn van de CPU-limiet van de server. Daarnaast zijn er natuurlijk ook factoren als temperatuur, batterijlading (in een laptop) en andere bijwerkingen als de processor constant op 100% draait. De prestatie-instelling zorgt voor de snelste processorprestaties. Lees bijvoorbeeld over force_turbo-parameter in Raspberry Pi, waarmee het RPi-paneel de regelaar gaat gebruiken prestatie, waarbij de prestatieverbetering meer merkbaar zal zijn vanwege de lage CPU-kloksnelheid.

Gebruik pm static om maximale serverprestaties te bereiken

PHP-FPM-optie pm statisch hangt grotendeels af van het vrije geheugen op de server. Als het geheugen laag is, is het beter om te kiezen op aanvraag of dynamisch. Aan de andere kant, als je geheugen hebt, kun je de overhead van PHP-procesbeheer vermijden door pm in te stellen statisch tot de maximale servercapaciteit. Met andere woorden, als alles goed is berekend, moet u dit vaststellen pm.statisch tot het maximale aantal PHP-FPM-processen dat kan worden uitgevoerd, zonder problemen te veroorzaken met weinig geheugen of cache. Maar niet zo hoog dat het de processors overweldigt en een heleboel PHP-FPM-bewerkingen opstapelt die wachten om te worden uitgevoerd.

In de bovenstaande schermafbeelding heeft de server pm = statisch en pm.max_children = 100, en dit neemt ongeveer 10 GB in beslag van de beschikbare 32. Let op de gemarkeerde kolommen, alles is hier duidelijk. In deze schermafbeelding waren er ongeveer 200 actieve gebruikers (meer dan 60 seconden) in Google Analytics. Op dit niveau is ongeveer 70% van de onderliggende PHP-FPM-processen nog steeds inactief. Dit betekent dat PHP-FPM altijd is ingesteld op de maximale hoeveelheid serverbronnen, ongeacht het huidige verkeer. Een inactief proces wacht op verkeerspieken en reageert onmiddellijk. U hoeft niet te wachten tot pm zal onderliggende processen aanmaken en deze vervolgens beëindigen wanneer de periode verstrijkt pm.process_idle_timeout. Ik heb de waarde op zeer hoog gezet pm.max_requestsomdat dit een werkende server is zonder geheugenlekken in PHP. Je kunt installeren pm.max_requests = 0 met static als je volledig vertrouwen hebt in 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 wij willen onnodige pm-kosten voorkomen. Tenminste, bijvoorbeeld pm.max_requests = 1000 - afhankelijk van hoeveelheid pm.max_kinderen en het aantal verzoeken per seconde.

De schermafbeelding toont de opdracht Linux-top, gefilterd op u (gebruiker) en PHP-FPM-gebruikersnaam. Alleen de eerste ongeveer 50 processen worden getoond (ik heb niet precies geteld), maar in wezen toont top de topstatistieken die in het terminalvenster passen. In dit geval gesorteerd op % CPU (%CPU). Om alle 100 PHP-FPM-processen te zien, voert u de opdracht uit:

top -bn1 | grep php-fpm

Wanneer pm ondemand en dynamisch gebruiken?

Als je pm dynamisch, komen dergelijke fouten voor:

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

Probeer de parameter te wijzigen, de fout zal niet verdwijnen, zoals beschreven in dit bericht op Serverfault. In dit geval was de pm.min-waarde te klein, en omdat het webverkeer zo sterk varieert en hoge pieken en diepe dalen kent, is het moeilijk om pm adequaat aan te passen dynamisch. Meestal wordt pm gebruikt op aanvraag, zoals geadviseerd in hetzelfde bericht. Maar dit is nog erger, omdat op aanvraag beëindigt inactieve processen tot nul wanneer er weinig of geen verkeer is, en u zult nog steeds eindigen met de overhead van veranderend verkeer. Tenzij je natuurlijk een enorme wachttijd instelt. En dan is het beter om te gebruiken pm.statisch + hoog aantal pm.max_requests.

PM dynamisch en vooral op aanvraag kan van pas komen als u meerdere PHP-FPM-pools heeft. U host bijvoorbeeld meerdere cPanel-accounts of meerdere websites in verschillende pools. Ik heb een server met bijvoorbeeld meer dan 100 cpanel-accounts en ongeveer 200 domeinen, en pm.static of zelfs dynamic zouden me niet redden. Het enige wat je hier nodig hebt is op aanvraagMeer dan tweederde van de websites ontvangt immers weinig of geen verkeer, en dat ook op aanvraag alle kindprocessen vallen weg, wat ons veel geheugen zal besparen! Gelukkig hebben de cPanel-ontwikkelaars dit opgemerkt en de waarde op standaard gezet op aanvraag. Vroeger, toen de standaard was dynamisch, PHP-FPM was helemaal niet geschikt voor drukke gedeelde servers. Velen hebben gebruikt suPHP, omdat pm dynamisch verbruikte geheugen, zelfs met inactieve pools en cPanel PHP-FPM-accounts. Als het verkeer goed is, wordt u hoogstwaarschijnlijk niet gehost op een server met een groot aantal PHP-FPM-pools (shared hosting).

Conclusie

Als u PHP-FPM gebruikt en er veel verkeer is, procesmanagers op aanvraag и dynamisch voor PHP-FPM zal de doorvoer beperkt zijn vanwege hun inherente overhead. Begrijp uw systeem en configureer PHP-FPM-processen op basis van de maximale servercapaciteit. Eerste set pm.max_kinderen afhankelijk van maximaal pm-gebruik dynamisch of op aanvraagen verhoog deze waarde vervolgens tot een niveau waarop het geheugen en de processor werken zonder overbelast te raken. Dat merk je bij pm statischOmdat je alles in het geheugen hebt, zullen verkeerspieken in de loop van de tijd minder CPU-pieken veroorzaken, en zullen de gemiddelde server- en CPU-belasting gelijk worden. De gemiddelde PHP-FPM-procesgrootte is afhankelijk van de webserver en vereist handmatige configuratie, dus meer geautomatiseerde procesmanagers zijn dat dynamisch и op aanvraag - meer populair. Ik hoop dat het artikel nuttig was.

UPD Benchmarkgrafiek toegevoegd ab. Als PHP-FPM-processen zich in het geheugen bevinden, nemen de prestaties toe ten koste van het geheugengebruik waar ze wachten. Vind de beste optie voor jezelf.

Bron: www.habr.com