Heim > Artikel > Backend-Entwicklung > Detaillierte Erläuterung der PHP-FPM-Startparameter und wichtiger Konfigurationen
Detaillierte Erläuterung der PHP-FPM-Startparameter und wichtigen Konfigurationen
Mehrere Verzeichnisse vereinbaren
Eins, php - Die Startparameter von fpm
2. Detaillierte Erläuterung wichtiger Parameter von php-fpm.conf
3. Häufige Fehler und Lösungen
1. Ressourcenprobleme, die durch request_terminate_timeout verursacht werden
Wenn der Wert von request_terminate_timeout auf 0 oder gesetzt ist Wenn es zu lange dauert, kann es zu Ressourcenproblemen mit file_get_contents kommen.
Wenn die von file_get_contents angeforderte Remote-Ressource zu langsam reagiert, bleibt file_get_contents immer dort hängen und es kommt zu keiner Zeitüberschreitung. Wir wissen, dass max_execution_time in php.ini die maximale Ausführungszeit von PHP-Skripten festlegen kann, aber in php-cgi (php-fpm) wird dieser Parameter nicht wirksam. Was die maximale Ausführungszeit von PHP-Skripten wirklich steuern kann, ist der Parameter request_terminate_timeout in der Konfigurationsdatei php-fpm.conf.
Der Standardwert von request_terminate_timeout beträgt 0 Sekunden, was bedeutet, dass das PHP-Skript weiterhin ausgeführt wird. Wenn alle PHP-CGI-Prozesse in der Funktion file_get_contents() stecken bleiben, kann dieser Nginx+PHP-WebServer auf diese Weise keine neuen PHP-Anfragen mehr verarbeiten und Nginx gibt „502 Bad Gateway“ an den Benutzer zurück. Die Änderung dieses Parameters ist erforderlich, um die maximale Ausführungszeit eines PHP-Skripts festzulegen, behandelt jedoch nur die Symptome und nicht die Grundursache. Ändern Sie ihn beispielsweise auf 30s, wenn file_get_contents() auftritt Wenn das Abrufen von Webseiteninhalten langsam ist, bedeutet dies, dass 150 PHP-CGI-Prozesse nur 5 Anfragen pro Sekunde verarbeiten können und es für WebServer auch schwierig ist, „502 Bad Gateway“ zu vermeiden. Die Lösung besteht darin, request_terminate_timeout auf 10 Sekunden oder einen angemessenen Wert zu setzen oder einen Timeout-Parameter zu file_get_contents hinzuzufügen.
2, Eine unsachgemäße Konfiguration des max_requests-Parameters kann zeitweise zu 502-Fehlern führen:
Genau aufgrund dieses Mechanismus werden 502-Fehler häufig auf Websites mit hoher Parallelität verursacht. Ich vermute, dass der Grund darin liegt, dass PHP-FPM die von NGINX kommende Anforderungswarteschlange nicht gut verarbeitet. Ich verwende jedoch immer noch PHP 5.3.2. Ich weiß nicht, ob dieses Problem in PHP 5.3.3 weiterhin besteht. Unsere aktuelle Lösung besteht darin, diesen Wert so groß wie möglich festzulegen, um die Anzahl der PHP-CGI-Re-SPAWNs so weit wie möglich zu reduzieren und gleichzeitig die Gesamtleistung zu verbessern. In unserer eigenen tatsächlichen Produktionsumgebung stellten wir fest, dass der Speicherverlust nicht offensichtlich war, daher haben wir diesen Wert sehr hoch eingestellt (204800). Jeder sollte diesen Wert entsprechend seiner tatsächlichen Situation festlegen und kann ihn nicht blind erhöhen.Im Allgemeinen verwenden wir in gewissem Umfang einige PHP-Bibliotheken von Drittanbietern. Wenn der PHP-CGI-Prozess nicht regelmäßig neu gestartet wird, treten zwangsläufig Probleme auf kontinuierlicher Speicherverbrauch. Daher stellt PHP-FPM als Manager von PHP-CGI eine solche Überwachungsfunktion bereit, um den PHP-CGI-Prozess neu zu starten, der eine bestimmte Anzahl von Malen angefordert hat, um sicherzustellen, dass die Speichernutzung nicht ansteigt.
Allerdings besteht der Zweck dieses Mechanismus nur darin, sicherzustellen, dass PHP-CGI nicht übermäßig viel Speicher belegt. Warum nicht durch Speichererkennung dagegen vorgehen? Ich stimme der Aussage von Gao Chunhui voll und ganz zu. Ein Neustart des PHP-CGI-Prozesses durch Festlegen der maximalen intrinsischen Nutzung des Prozesses wäre eine bessere Lösung.