mbstef
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Moin liebe Leute, ich betreibe einen vServer (2 vCores, 8GB Ram) vor allem auch um mich in diesen Dingen selbst weiterzubilden mit Ubuntu-Server 16.04, Nginx und PHP-FPM. Seit einigen Tagen ist es nun so, dass sporadisch die installierten vHosts immer wieder vor allem morgens einen 502 Gateway Timeout liefern. Die error-logs zeigen eigentlich nix besonderes an (außer eben diese 502 Errros). Starte ich Nginx neu, ändert dies nichts. Starte ich php-fpm neu, funktioniert es wieder und das Problem scheint behoben. Ich habe schon diverse Google Ergebnisse durch, geändert hat dies nichts. Leider fehlt mir ehrlich gesagt auch der Ansatz, wo ich hier schauen und entsprechende Lösungen suchen könnte. Wo setzt man hier an?
|
Tronde
Anmeldungsdatum: 23. November 2006
Beiträge: 1640
|
Moin, sporadische Fehler sind immer doof. Für eine Fehleranalyse wäre es natürlich schön, wenn du das Problem reproduzieren könntest, um es besser analysieren zu können. Läuft denn noch ein PHP-FPM-Prozess, wenn das Problem besteht? Und nimmt dieser noch Anfragen zur Verarbeitung an? Dies sind nun nur wilde Vermutungen. Poste doch mal bitte die Logdateien für den entsprechenden Zeitabschnitt für NGINX und PHP-FPM hier im Codeblock. Dann kann dir evtl. besser weitergeholfen werden. MfG Tronde
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
Man kann sicher auch auf php-fpm ein paar Logfiles rausbekommen, dort kann man gezielt schauen was passiert und warum etwas abraucht. mfg Stefan
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Leider weiß ich jetzt nicht mehr genau, wann das letzte mal das aufgetreten ist. Ich vermute allerdings, dass es die kommende Zeit wieder passieren wird und sobald das geschieht, poste ich mal beide Logs hier. Danke schonmal.
|
Tronde
Anmeldungsdatum: 23. November 2006
Beiträge: 1640
|
Bis das Problem wieder auftritt kannst du ja mal schauen, wie die Loglevel eingestellt sind und diese evtl. heraufsetzen, um ausführlichere Informationen im Fehlerfall zu erhalten.
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
So heute morgen war es wieder soweit. Hier mal die Logs: /var/log/nginx/error.log
| 2017/08/08 02:00:13 [error] 920#920: *61298 access forbidden by rule, client: 138.99.15.146, server: *.wpler.com, request: "GET /xmlrpc.php HTTP/1.1", host: "wpler.com"
2017/08/08 02:01:13 [error] 920#920: *61309 connect() to unix:/run/php/php7.0-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 138.99.15.146, server: *.wpler.com, request: "GET /wp-login.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "wpler.com"
|
/var/log/php7.0-fpm.log
| [08-Aug-2017 01:06:15] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[08-Aug-2017 01:07:42] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
|
Die letzte Zeile in der nginx/error.log zieht sich so bis jetzt aktuell auf diversen vHosts fast sekündlich durch. Starte ich jetzt php-fpm neu, funktionieren die vHosts wieder alle. Wie geht man jetzt weiter vor? Ich sehe hier nur heraus, dass der php-fpm sock wohl offenbar nicht mehr läuft, also php-fpm abgestürzt ist. Danke schonmal,
|
Tronde
Anmeldungsdatum: 23. November 2006
Beiträge: 1640
|
Guten Morgen mbstef, der interessante Teil steht in deinem PHP-FPM-Log. Dieses besagt, dass aktuell keine Kindprozesse zur Verarbeitung von Anfragen zur Verfügung stehen. PHP-FPM ist also nicht abgestürzt, sondern beschäftigt. Ein Neustart von PHP-FPM bewirkt, dass nun alle in Bearbeitung befindlichen Anfragen abgebrochen werden und dein Pool wieder frei ist, um neue Anfragen zu verarbeiten. Prüfe auf welchen Wert der Parameter pm.max_children bei der eingestellt ist und verdoppel diesen versuchsweise (vorausgesetzt dein Host besitzt genügend Arbeitsspeicher, um die zusätzlichen Prozesse ausführen zu können). Betreibst du mehrere Webanwendungen auf deinem Host, kannst du überlegen weitere PHP-FPM-Pools einzurichten und für große Webanwendungen eigene Pools zu nutzen. MfG Tronde
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Moin Tronde, also es handelt sich um einen vServer mit 8GB Ram. Htop zeigt mir regelmäßig eine Auslastung des Rams von durchschnittlich 2GB an. Swappen tut er eigentlich nie. in der /etc/php/7.0/fpm/pool.d/www.conf steht
| pm = dynamic
pm.max_children = 5
pm.min_spare_servers = 1
pm.max_spare_servers = 3
|
Ich erinnere mich, dass ich daran auch mal rumgeschraubt habe, weil ich aber nicht genau wußte, was ich da tue habe ich das so eingestellt, wie das jetzt ist. Da gibt es doch glaube ich eine Berechnungsformel, oder? Ich betreibe darauf eigentlich nur 8 Domains mit jeweils WordPress, 2 der Domains sind Multiblogs mit mindestens 2 Subblogs darin. Keines der Domains hat größeren Traffic, eher im unteren Bereich. Daher auch nur der vServer 😉 Ich habe den Wert pm.max_children mal auf 10 gestellt. Mal schauen, ob das jetzt auch noch passiert. Danke Dir,
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
5 Children für 8 GB ist nichts. Klar hängt da fpm öfters wenn dein PHP Prozess länger braucht und somit keine children worker mehr frei sind um neue anfragen entgegen zu nehmen. nginx warten dann bis zum proxy timeout. Lesematerial: https://serversforhackers.com/c/php-fpm-process-management
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Danke TheDarkRose, ich habe jetzt mal
| pm.max_children = 60
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
|
gesetzt. Sollte ja nach der Formel auf der verlinkten Seite so ungefähr hinkommen (=(1024*8) / 140 - 140MB verbraucht lt. htop php im Durchschnitt). Mal schauen, ob das wieder passiert.
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Hm, Mist.. 60 childrens reichen offenbar auch nicht. Was kann ich machen?
|
jb-alvarado
Anmeldungsdatum: 28. November 2012
Beiträge: 345
|
Ich hatte erst vor kurzen ähnliche Problem, allerdings hatte ich für eine Webseite nginx als reverse Proxy vor Apache geschaltet. In Apache hatte ich einen Parameter drin der verhindert hat, dass sich die php-fpm Prozesse wieder schließen. Das hat dazu geführt das nach einer Zeit keine php-fpm Instanzen mehr für die Webseiten über waren, die direkt von nginx verarbeitet werden. Da solltest du vielleicht auch mal schauen, ob das bei dir passiert. Ansonsten könntest auch noch diese Parameter testen: | pm = ondemand
pm.process_idle_timeout = 10s;
|
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Hallo jb-alvarado, nein Apache habe ich definitiv nicht auf der Kiste drauf oder vorgeschaltet. Derzeit steht pm auf dynamic. Ich habe das jetzt mal umgestellt. Ich berichte die Tage wieder. Danke dir,
|
jb-alvarado
Anmeldungsdatum: 28. November 2012
Beiträge: 345
|
mbstef schrieb:
Hallo mbstef, du kannst das auch ganz schnell testen: Mache mit wrk, oder ab einen Stresstest. Mit z.B. htop siehst du sofort wie die php-hpm worker angehen, bis dein Limit voll ist. Mit gesetzten pm.process_idle_timeout = 10s; sollten 10 Sekunden nachdem der Stresstest vorbei ist die worker Anzahl wieder runter gehen. Am wichtigst ist dass du das Problem behoben bekommst, allerdings kannst du zusätzlich auch verschiedene php-fpm - www.conf nutzen. Dann hättest du z.B. per Domain festgelegte Instancen.
|
mbstef
(Themenstarter)
Anmeldungsdatum: 24. Februar 2008
Beiträge: 121
Wohnort: Palma de Mallorca
|
Hallo jb-alvarado, ich habe gerade mal ein ab-test gemacht, tatsächlich ist die Anzahl an child nach 10s wieder deutlich runter und auch die zusätzlichen master-prozesse sind wieder runter gegangen. folgenden test hab ich durchlaufen lassen:
| ab -kc 1000 -n 10000 https://domain.tld
|
Nach dem Test liefen die Seiten auch noch (wenn auch etwas langsam). Bis jetzt ist das Problem auch noch nicht wieder aufgetreten. Danke Dir,
|