Eine unbearbeitete Version des Artikels wurde ursprünglich auf haydenjames.io veröffentlicht und wird hier mit Genehmigung des Autors veröffentlicht .
Kurz gesagt, ich werde darüber sprechen, wie PHP-FPM am besten konfiguriert werden kann, um den Durchsatz zu erhöhen, die Latenz zu verringern und die Prozessorressourcen und den Arbeitsspeicher stabiler zu nutzen. Standardmäßig ist die Zeichenfolge PM (Prozessmanager) in PHP-FPM dynamisch . Wenn Sie nicht über genügend Speicher verfügen, ist es besser, ondemand zu installieren. Vergleichen wir zwei Steuerungsoptionen basierend auf der php.net-Dokumentation und sehen, wie sich meine bevorzugte statische PM für eine große Menge an Verkehr von ihnen unterscheidet:
pm = dynamic - Die Anzahl der untergeordneten Prozesse wird basierend auf den folgenden Anweisungen dynamisch konfiguriert: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers .
pm = ondemand - Prozesse werden bei Bedarf erstellt (im Gegensatz zur dynamischen Erstellung, wenn pm.start_servers beim Start des Dienstes gestartet werden).
pm = static - Die Anzahl der untergeordneten Prozesse wird festgelegt und durch den Parameter pm.max_children angegeben .
Weitere Informationen finden Sie in der vollständigen Liste der globalen Anweisungen php-fpm.conf .
Die Ähnlichkeiten des PHP-FPM-Prozessmanagers mit dem Prozessorfrequenzregler
Es mag offtopisch erscheinen, aber ich werde dies mit dem PHP-FPM-Konfigurationsthema in Verbindung bringen. Wer mindestens einmal den Prozessor nicht verlangsamt hat - auf einem Laptop, einer virtuellen Maschine oder einem dedizierten Server. Erinnern Sie sich an die Skalierung der Prozessorfrequenz? Diese für nix und Windows verfügbaren Optionen können die Systemleistung und Reaktionsfähigkeit verbessern, indem die Einstellung des Prozessorcontrollers von On-Demand auf Leistung * geändert wird. Vergleichen wir diesmal die Beschreibungen und sehen uns die Ähnlichkeiten an:
Governor = ondemand - dynamische Skalierung der Prozessorfrequenz in Abhängigkeit von der aktuellen Last. Schaltet scharf auf die maximale Frequenz um und reduziert sie dann, wenn die Leerlaufzeiten zunehmen.
Regler = konservativ = dynamische Frequenzskalierung in Abhängigkeit von der aktuellen Last. Erhöht und verringert die Frequenz gleichmäßiger als bei Bedarf.
Regler = Leistung - die Frequenz ist immer maximal.
Weitere Informationen finden Sie in der vollständigen Liste der Parameter des Prozessorfrequenzreglers .
Sehen Sie die Ähnlichkeit? Ich wollte diesen Vergleich zeigen, um Sie davon zu überzeugen, dass es am besten ist, pm static für PHP-FPM zu verwenden.
Bei einem Prozessor-Controller hilft der Leistungsparameter dabei , die Leistung sicher zu steigern, da er fast ausschließlich vom Server-Prozessor-Limit abhängt. Darüber hinaus gibt es natürlich auch Faktoren wie Temperatur, Akkuladung (in einem Laptop) und andere Nebenwirkungen eines konstanten Prozessorbetriebs bei 100%. Die Leistungsoptimierung bietet die schnellste Prozessorleistung. Lesen Sie zum Beispiel den Parameter force_turbo im Raspberry Pi , mit dem das RPi-Panel die Leistungssteuerung verwendet, wobei die Leistungsverbesserung aufgrund der niedrigen Taktrate der CPU deutlicher wird.
Verwenden von pm static zur Maximierung der Serverleistung
Der statische Parameter PHP-FPM pm hängt weitgehend vom freien Speicher auf dem Server ab. Wenn der Arbeitsspeicher niedrig ist, ist es besser, On-Demand oder Dynamic zu wählen. Wenn Sie jedoch über Speicher verfügen, können Sie den Overhead des PHP-Prozessmanagers vermeiden, indem Sie pm static auf die maximale Serverkapazität einstellen. Mit anderen Worten, wenn alles gut berechnet ist, müssen Sie pm.static auf die maximale Anzahl von PHP-FPM-Prozessen einstellen , die ausgeführt werden können, ohne Probleme mit unzureichendem Speicher oder Cache zu verursachen. Aber nicht so hoch, dass die Prozessoren überlastet werden und eine Reihe von PHP-FPM-Operationen angesammelt werden, die auf ihre Ausführung warten .
Im obigen Screenshot sind auf dem Server pm = static und pm.max_children = 100 installiert. Dies erfordert etwa 10 GB der 32 verfügbaren. Beachten Sie die hervorgehobenen Spalten. Hier ist alles klar. In diesem Screenshot waren ungefähr 200 aktive Nutzer (über 60 Sekunden) in Google Analytics. Auf dieser Ebene sind ungefähr 70% der untergeordneten PHP-FPM-Prozesse noch inaktiv. Dies bedeutet, dass PHP-FPM unabhängig vom aktuellen Datenverkehr immer auf die maximale Menge an Serverressourcen eingestellt ist. Ein Leerlaufprozess wartet auf Verkehrsspitzen und reagiert sofort. Sie müssen nicht auf pm warten , um untergeordnete Prozesse zu erstellen, und diese dann beenden, wenn der Zeitraum pm.process_idle_timeout abläuft . Ich habe einen sehr hohen Wert für pm.max_requests festgelegt , da es sich um einen funktionierenden Server ohne Speicherlecks in PHP handelt. Sie können pm.max_requests = 0 mit static festlegen, wenn Sie mit vorhandenen und zukünftigen PHP-Skripten vertraut sind. Es ist jedoch besser, die Skripte im Laufe der Zeit neu zu starten. Installieren Sie eine große Anzahl von Abfragen, da wir den unnötigen Overhead von pm vermeiden möchten. Zum Beispiel mindestens pm.max_requests = 1000 - abhängig von der Anzahl der pm.max_children und der Anzahl der Anforderungen pro Sekunde.
Der Screenshot zeigt den Linux- Befehl top , gefiltert nach u (Benutzer) und PHP-FPM-Benutzername. Es werden nur die ersten 50 Prozesse angezeigt (ich habe nicht genau gezählt), aber oben werden die Top-Statistiken angezeigt, die im Terminalfenster platziert sind. In diesem Fall sortiert nach% CPU (% CPU). Führen Sie den folgenden Befehl aus, um alle 100 PHP-FPM-Prozesse anzuzeigen:
top -bn1 | grep php-fpm
Wann ist pm ondemand und dynamisch zu verwenden?
Wenn Sie pm dynamic verwenden , werden ähnliche Fehler angezeigt:
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
Versuchen Sie, den Parameter zu ändern. Der Fehler tritt nirgendwo auf, wie in diesem Beitrag zu Serverfault beschrieben . In diesem Fall war der Wert von pm.min zu klein, und da sich der Webverkehr stark ändert und hohe Spitzen und tiefe Abfälle aufweist, ist es schwierig, die pm- Dynamik angemessen zu konfigurieren. Dies verwendet normalerweise pm ondemand , wie im selben Beitrag empfohlen . Dies ist jedoch noch schlimmer, da bei Bedarf Leerlaufprozesse auf Null beendet werden, wenn wenig oder gar kein Datenverkehr vorhanden ist. Infolgedessen leiden Sie immer noch unter Kosten, wenn sich der Datenverkehr ändert. Es sei denn, Sie haben eine große Wartezeit festgelegt. Und dann ist es besser, pm.static + eine hohe Anzahl von pm.max_requests zu verwenden .
PM- Dynamik und insbesondere On-Demand können nützlich sein, wenn Sie über mehrere PHP-FPM-Pools verfügen. Sie hosten beispielsweise mehrere cPanel-Konten oder mehrere Websites in verschiedenen Pools. Ich habe einen Server, auf dem zum Beispiel mehr als 100 Cpanel-Konten und etwa 200 Domains und pm.static oder sogar Dynamic mich nicht retten würden. Hier wird nur On-Demand benötigt, da mehr als zwei Drittel der Websites nur wenig oder gar keinen Datenverkehr erhalten und bei On-Demand alle untergeordneten Prozesse abfallen, was uns viel Speicherplatz spart! Glücklicherweise haben cPanel-Entwickler dies bemerkt und den Standardwert auf ondemand gesetzt . Bisher war PHP-FPM, wenn der Standardwert dynamisch war, überhaupt nicht für ausgelastete gemeinsam genutzte Server geeignet. Viele verwendeten suPHP, weil pm dynamic selbst bei inaktiven Pools und cPanel PHP-FPM-Konten Speicher verbrauchte. Bei gutem Datenverkehr werden Sie höchstwahrscheinlich nicht auf einem Server mit einer großen Anzahl von PHP-FPM-Pools (Shared Hosting) gehostet.
Fazit
Wenn Sie PHP-FPM verwenden und viel Verkehr haben, begrenzen die On-Demand- und dynamischen Prozessmanager für PHP-FPM die Bandbreite aufgrund ihrer inhärenten Kosten. Untersuchen Sie Ihr System und konfigurieren Sie Ihre PHP-FPM-Prozesse so, dass sie Ihrer maximalen Serverkapazität entsprechen. Stellen Sie zuerst pm.max_children ein, abhängig von der maximalen Verwendung von pm dynamic oder ondemand , und erhöhen Sie diesen Wert dann auf das Niveau, auf dem Speicher und Prozessor ohne übermäßige Überlastung arbeiten. Sie werden feststellen, dass bei pm static , da alles im Speicher gespeichert ist, Verkehrsspitzen im Laufe der Zeit weniger Spitzen für den Prozessor verursachen und die durchschnittlichen Server- und Prozessorlastwerte ausgeglichen werden. Die durchschnittliche PHP-FPM-Prozessgröße hängt vom Webserver ab und erfordert eine manuelle Konfiguration. Daher sind die stärker automatisierten Prozessmanager - dynamisch und bedarfsgesteuert - beliebter. Hoffe der Artikel war hilfreich.
UPD Benchmark-Diagramm hinzugefügt ab . Wenn sich die PHP-FPM-Prozesse im Speicher befinden, wird die Leistung verbessert, indem der Speicher dort belegt wird, wo sie sitzen und warten. Finden Sie die beste Option für sich.
