Fehlerbehebung bei der Ursache des 502 Bad Gateway-Fehlers auf dem Nginx-Server

Der Server meldet einen Fehler 502 beim Synchronisieren der Fandaten des öffentlichen Kontos und beim Batch-Pushing

Anhand der Fehlermeldung lässt sich feststellen, dass es sich um ein Backend-Problem handelt. Es gibt viele Gründe für 502-Fehler, aber im Allgemeinen kann der Server damit nicht umgehen.

1. Überprüfen Sie zunächst das Serverprotokoll
1) Überprüfen Sie zuerst das Nginx-Protokoll. Wenn Sie damit nicht vertraut sind, können Sie den Pfad von error_log aus nginx.conf abrufen und den Fehler wie folgt finden:

Es wurde festgestellt, dass die Anzahl der vom Nginx-Prozess verarbeiteten Verbindungen nicht ausreicht und die Anzahl der von einem einzelnen Prozess verarbeiteten Verbindungen den in nginx.conf konfigurierten Wert worker_connections überschreitet.

Normalerweise kann sich der Wert von worker_connections auf die maximale Anzahl von Verbindungen beziehen, die von einem einzelnen Prozess geöffnet werden. Der Befehl lautet: ulimit -n
ulimit -a Alle Limit-Parameter anzeigen. Die aktuelle maximale Anzahl geöffneter Dateien beträgt 65535. Sie können worker_connections auf 51200 setzen.

Starten Sie nginx neu nginx -s reload

Den aktuellen TCP-Verbindungsstatus anzeigen netstat -an|awk '/^tcp/{++S[$NF]}END{for (a in S)print a,S[a]}'

2) Überprüfen Sie das php-fpm-Protokoll. Wenn Sie den Speicherort des Protokolls nicht kennen, können Sie ihn in php-fpm.conf überprüfen. Beachten Sie, dass die Konfigurationsdatei für php7 und höher im Verzeichnis www.conf unter dem Verzeichnis php-fpm.d abgelegt ist.

php-fpm.log anzeigen

Es wurde festgestellt, dass pm.max_children nicht ausreicht, was darauf hinweist, dass die maximale Anzahl von PHP-FPM-Prozessen zu gering ist. Überprüfen Sie die PHP-Konfigurationsdatei ww.conf und ändern Sie den Parameter pm.max_children = 100

php-fpm passt hauptsächlich mehrere Parameter an
pm = dynamisch So steuern Sie den untergeordneten Prozess. Optionen sind statisch und dynamisch.

pm.max_children: Die Anzahl der im statischen Modus geöffneten php-fpm-Prozesse pm.max_requests: Die maximale Anzahl von Anfragen, die ein untergeordneter php-fpm-Prozess verarbeiten kann pm.start_servers: Die Anzahl der startenden php-fpm-Prozesse im dynamischen Modus pm.min_spare_servers: Die Mindestanzahl von php-fpm-Prozessen im dynamischen Modus pm.max_spare_servers: Die maximale Anzahl von php-fpm-Prozessen im dynamischen Modus

1. Was ist der entsprechende Wert für pm.max_children und pm.max_spare_servers?

Grundsätzlich gilt: Je größer dieser Wert ist, desto besser. Wenn mehr PHP-CGI-Prozesse vorhanden sind, ist die Verarbeitung schneller und es stehen weniger Anfragen in der Warteschlange.
Die Einstellung „max_children“ muss ebenfalls entsprechend der Leistung des Servers vorgenommen werden.

Die Zahl kann auch basierend auf dem Speicher/30 M ermittelt werden. Wenn der Speicher beispielsweise 8 GB beträgt, kann er auf 100 gesetzt werden, sodass der von php-fpm verbrauchte Speicher auf etwa 2 G-3 G gesteuert werden kann.

Bei einem Server mit wenig Speicher, beispielsweise einem VPS mit 256 MB Speicher, verbrauchen 10 PHP-CGI-Prozesse 200 MB Speicher, selbst wenn Sie die Berechnung auf der Grundlage einer Speicherkapazität von 20 MB durchführen. Ein Systemabsturz ist daher normal.

Daher sollten wir versuchen, die Anzahl der PHP-FPM-Prozesse zu kontrollieren und einen groben Überblick über den von anderen Anwendungen belegten Speicher zu bekommen.
Durch die Zuweisung eines kleinen statischen Betrags wird das System stabiler. Oder verwenden Sie die dynamische Methode,
Da bei der dynamischen Methode unnötige Prozesse beendet und etwas Speicher zurückgewonnen wird, empfiehlt es sich, sie auf Servern oder VPSs mit weniger Speicher zu verwenden. Die spezifische Maximalzahl ergibt sich aus dem Speicher/30 M.

Die Standardwertberechnungsformel von pm.start_servers lautet: min_spare_servers + (max_spare_servers - min_spare_servers) / 2.

Wenn Sie beispielsweise einen 512-M-VPS haben und php-fpm maximal 250 M zuweisen, wird empfohlen, pm.max_spare_servers auf 250/30 zu setzen, was ungefähr 8 entspricht. Was pm.min_spare_servers betrifft, wird empfohlen, es entsprechend der Serverlast einzustellen. Wenn beispielsweise nur die PHP-Umgebung auf dem Server bereitgestellt wird, liegt der geeignetere Wert zwischen 2 und 5.

Hier gibt es noch ein weiteres Problem. php-fpm kann aufgrund einiger Drittanbieterbibliotheken Speicherlecks verursachen. Mit der Zeit wird dadurch mehr Speicher belegt. Beispielsweise belegt unser Server jetzt etwa 50 m. Glücklicherweise gibt es den Parameter pm.max_requests, der angibt, wie oft ein untergeordneter php-fpm-Prozess ausgeführt wird, bevor der Prozess neu gestartet wird. Dies muss möglicherweise entsprechend Ihrer tatsächlichen Situation angepasst werden.

Die Berechnung erfolgt wie folgt:

Im Allgemeinen beträgt der von jedem PHP-CGI auf einem Server unter normalen Umständen verbrauchte Speicher etwa 20–30 MB, daher stelle ich meine „max_children“ auf 40 ein, 20 MB * 40 = 800 MB. Dies bedeutet, dass zu Spitzenzeiten der von allen PHP-CGIs verbrauchte Speicher innerhalb von 800 MB liegt, was unter meinem effektiven Speicher von 2 GB liegt.

Wenn mein „max_children“ auf einen kleineren Wert wie 5–10 eingestellt ist, wird php-cgi „sehr müde“, die Verarbeitungsgeschwindigkeit wird sehr langsam, die Wartezeit wird lang und die CPU-Auslastung wird hoch.

Wenn eine Anforderung über einen längeren Zeitraum nicht verarbeitet wird, wird der Fehler „504 Gateway Time-out“ angezeigt, und wenn beim verarbeiteten PHP-CGI ein Problem auftritt, wird der Fehler „502 Bad Gateway“ angezeigt.

Die beste Möglichkeit zum Festlegen von max_children basiert auf req/s
(Durchsatz, die maximale Anzahl von Anfragen, die der Server pro Zeiteinheit verarbeitet, unit req/s) einzustellen,
Wenn das Programm eine Verarbeitungskapazität von 100 Anf./s hat, ist es besser, den Wert auf 100 einzustellen. Dies wird dynamisch angepasst.

2. Was ist der entsprechende request_terminate_timeout-Wert?

Die Berechnung erfolgt wie folgt:

Wenn die Leistung Ihres Servers gut genug ist, die Bandbreitenressourcen ausreichen und das PHP-Skript keine Loops oder Bugs aufweist, können Sie „request_terminate_timeout“ direkt auf 0s setzen. 0s bedeutet, dass PHP-CGI ohne Zeitbegrenzung weiter ausgeführt wird.

Wenn dies nicht möglich ist, Ihr PHP-CGI also einen Fehler aufweist, Ihre Bandbreite nicht ausreicht oder Ihr PHP-CGI aus anderen Gründen hängen bleibt, dann empfiehlt es sich, „request_terminate_timeout“ einen Wert zuzuweisen, der je nach Leistung Ihres Servers eingestellt werden kann.

Generell gilt: Je besser die Leistung, desto höher können Sie sie einstellen, 20 Minuten bis 30 Minuten sind in Ordnung. Da die Ausführung meiner Server-PHP-Skripte lange dauern kann und manche davon 10 Minuten überschreiten, habe ich 900 Sekunden eingestellt. Dadurch wird PHP-CGI nicht abgebrochen und es tritt kein 502 Bad Gateway-Fehler auf.

Optimierte Parameter

Bearbeiten Sie /usr/local/php/etc/php-fpm.d/www.conf:
Serverkonfiguration: 2 Kerne 8G
pm = dynamisch
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 100

Anfrage_Beenden_Zeitüberschreitung=1200

Finden Sie die Prozess-ID des Dienstes heraus
ps aux |grep php-fpm
kill -9 process id wird oft verwendet, um Zombie-Prozesse zu beenden

Fassen Sie die Ursachen für 502-Fehler in Nginx zusammen

2. Der Proxy-Puffer ist zu klein. Wenn Sie den Reverse-Proxy von Nginx verwenden und der Header zu groß ist und den Standardwert von 1 KB überschreitet, führt dies dazu, dass der Upstream den oben erwähnten zu großen Header sendet (um es klar auszudrücken: Nginx sendet die externe Anforderung zur Verarbeitung an das Backend, und der vom Backend zurückgegebene Header ist zu groß, sodass Nginx ihn nicht verarbeiten kann, was zu 502 führt).

Server {

hören Sie 80;
Servername *.lxy.me;

Standort / {

Fügen Sie diese 3 Zeilen hinzu
fastcgi_buffer_size 64k;
fastcgi_buffers 32 32k;
fastcgi_busy_buffers_size 128k;
Fügen Sie diese 3 Zeilen hinzu
Proxy_Set_Header Host $host;
Proxy_Set_Header X-Real-IP $Remote_Addr;
proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
…………
}

3. Die Standardanzahl der PHP-CGI-Prozesse ist zu klein eingestellt. Bei der Installation und Verwendung können 502-Probleme auftreten. Im Allgemeinen liegt dies daran, dass die Standardanzahl der PHP-CGI-Prozesse 5 beträgt. 502 kann durch unzureichende PHPCGI-Prozesse verursacht werden. Sie müssen /usr/local/php/etc/php-fpm.conf ändern und den max_children-Wert entsprechend erhöhen. Es ist auch möglich, dass der max_requests-Wert nicht ausreicht. Es ist zu beachten, dass diese beiden Konfigurationselemente viel Speicher beanspruchen. Bitte stellen Sie sie entsprechend der Serverkonfiguration ein. Andernfalls könnte es den gegenteiligen Effekt haben.

4. PHP-Ausführungstimeout
PHP-Ausführungstimeout, ändern Sie /usr/local/php/etc/php.ini und ändern Sie max_execution_time auf 300

5. Nginx-Wartezeit-Timeout Die Ausführungszeit einiger PHP-Programme überschreitet die Nginx-Wartezeit. Sie können die FastCGI-Timeout-Zeit in der Konfigurationsdatei nginx.conf entsprechend erhöhen

http {
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
…
}

6. Wenn Sie an einem öffentlichen Konto arbeiten, beachten Sie bitte, dass dies möglicherweise durch zu viele Anfragen vom WeChat-Server an Ihren eigenen Server verursacht wird. Wenn Sie feststellen, dass die Anzahl der php-fpm-Prozesse die maximale Anzahl von Prozessen erreicht hat, überprüfen Sie die php-fpm-Konfigurationsdatei und Sie erhalten eine Fehlermeldung.

Dies ist das Ende dieses Artikels zur Fehlerbehebung bei der Ursache der Nginx-Serverausnahme 502 Bad Gateway. Weitere verwandte Inhalte zur Nginx-Serverausnahme 502 Bad Gateway finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!