Server/Hosting PHP-FPM mit teils exorbitant hohem Speicherverbrauch

[otto]

Hallo,

Unix Server (Ubuntu LTS),
MariaDB aktuell,
Apache2 + nginx aktuell, (php-fpm, event)
64GB Ram,
DB auf SSD,
Plesk Obsidian aktuell




Detailierter:




Pfeil 1 = Beginn, Ausfall
Pfeil 2 = Reboot, erst einmal alles OK

Wie man schön sehen kann (30 Tage im Blick) spinnt mein PHP-FPM gerade etwas rum. Die Quittung ist am Ende das Seiten nicht mehr geladen werden (Pfeil 1), es kommt zu time-outs (z.B. 504 oder 502).


Hat jemand nen Tipp, wie ich dem auf die Schliche kommen kann?
Aktuell schaut es nach nem reboot (nach 2h erfolgloser Versuche das Thema in den Griff zu bekommen) so aus:

Also erstmal recht normal mMn.

Zuvor hatte ich jedoch einen child der sich 5,4 Gb (!!) genehmigte (vor dem Reboot). Bei max 4 childs + dem Rest der Speicherverbraucher (DB ca. 1,1 Gb, Rest ca. 400 MB) war da natürlich schnell mal Schluss mit lustig bei 64 Gb Ram im Server.

Edit: ca. 1h später:

aktuell schwankt das Maximum um die 95-99 MB jeweils ...
und insgesamt:

etwas detailierter:

Aktuell um die 450-500 Mb statt zuvor rund 28,8 Gb im peak.

Laaangfristig betrachtet - schaukelt sich das System offenbar gern mal auf:
Letzte 90 Tage:


Letzte 30 Tage:

Es kam auch immer mal wieder morgens (aber nicht täglich) zu nicht erreichbaren Seiten (meist nginx 504er) was aber stets nur sehr kurz anhielt und wo och zunächst dachte, OK - keine 10 Gb, war ne Lastspitze, weiter beobachten.
Aber die letzte, heutige Eskaltion auf 28,8 Gb war dann doch zu heftig und lies sich auch nicht durch einen simplen Neustart von nginx und apache oder auch php-fpm auflösen. Erst ein reboot brach den peak dann.



unter etc/php/7.2/fpm/php.ini sind 128 MB als Limit eingetragen:


Jetzt hab ich auf dem Server aber neben php 7.2 auch noch 7.3, 7.4 und eine ältere Version aus Kompatibilitätsgründen laufen - gilt diese php.ini nun für ALLE php Versionen oder nur für diese eine? Wo finde ich auf die Schnelle die anderen dann ggf.?

in der zugehörigen etc/php/7.2/fpm/pool.d/www.conf ist das meiste auskommentiert. (default)
aktiv sind an Einstellungen u.a.:
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Geh ich da nun händisch bei (unter Anbetracht des Plesk Obsidian auf dem Server) oder gibts nen anderen Punkt wo man diese Einstellungen Server-weit setzen kann? Gelten diese Server-weit für ALLE PHP Versionen oder nur für jeweils eine der installierten?


Wie komme ich einem einzelnen Amok laufenden php-fpm child auf die Schliche, weshalb er aus dem Ruder läuft? Jemand ne Idee zur Hand?

 

[otto]

Hier gibts nen Link, wo einer beschreibt wie er die Werte kalkuliert und setzt - was ist davon zu halten?
Determining the correct number of child processes for PHP-FPM on NGinx
oder:
PHP und Apache-Webserver für optimale Leistung einrichten – Privatstrand
Begrenzen Sie den PHP-FPM-Speicherverbrauch

Viele empfehlen stumpf die max execution time hoch zu setzen, was ich aber nicht befürworten kann solange der Speicherverbrauch so exorbitant ansteigen kann wie heut morgen erstmals geschehen.
How to Fix 504 Gateway Timeout using Nginx

 

[otto]

@McAtze
Könntest das hier bitte zu Technik und co schieben? Dankeschön.

 

[otto]

Danke Atze!

Zwischenstand:
PHP-FPM Speicherauslastung ist dezent auf 545-585 Mb angestiegen, mal sehen wohin die Fuhre nun geht, ich beobachte das nun alle paar Stunden um diesmal eher eingreifen zu können.

 

[Hoffi]

Danke für den Bericht. Ich bin gespannt was bei rauskommt.

 

[otto]

Was mich stutzig macht, ist auch die deutlich markant angestiegene CPU Last kurz vorm K.O.:


Ich mein, das ist nichts, was die CPU ernsthaft in die Knie zwingt, aber der recht abrupte Anstieg ist ja dann doch sehr deutlich in einem Verlauf über 3 Monate zu sehen. Möglicherweise kam diese im Zusammenhang mit der zunehmenden Auslagerung durch den voll gelaufenen RAM?
Im Detail stieg die Apache CPU-Last und die MySQL CPU Last sichtbar an.

Die reelle Speicherauslastung gleicher Zeitraum wie zuvor:

Die hohe CUP-Last ging mit voll laufendem Speicher einher wobei gleichermaßen und stetig die Auslagerung aufs Laufwerk erhöht wurde.
Am 20.3. gegen 00:00 Uhr stieg die Speicherauslastung sprunghaft 4,5 auf 34,5 GB (grün) an - Warum? Ich werde versuchen es den Logfiles zu entlocken. Was mich stutzig macht, ist das Sägezahnartige Profil der Speicherauslastung durch den Cache (gelb) was ich noch als normal abtuen könnte, wäre das im Tagesrythmus korrelierend zu den Besucherzahlen - aber dem ist nicht so. die Sägezähne haben eine zeitliche länge von recht genau 7 Tage. Wieder und wieder 7 Tage, von Tal zu Tal, von peak zu peak.
Dabei sind die Täler und peaks mal morgens, mal Nachmittags, mal Abends, also unregelmäßig.

Schauen wir auf die Auslagerungsdatei im gleichen Zeitraum:

Auch hier sind die Stufen im 7 Tage-Rythmus ausgeprägt erkennbar.

Interessant (für die Fehlersuche) der Einbruch nach dem peak kommt stets an einem Sonntag! Aber wie gesagt zu unterschiedlichsten Tageszeiten. Ebenso bei der CUP-Last.

Schauen wir mal auf die Netzwerkanbindung nach außen - die Netzwerkschnittstelle:

Gleiches Bild. Alle 7 Tage an einem Sonntag ein peak und dann ein einbrechen auf normale Werte.



Ich bin im Moment noch ratlos, was all das auslöst.

Schauen wir mal auf ein Ereignis und dessen zeitlichen Ablauf:

Hier wurde am 21.3. umd 12:54 Uhr ein starker Anstieg beim Datentransfer (ausgehend: tx (gelb) / eingehend: rx (grün)) verzeichnet.

12:59 Uhr wurde ein Anstieg der CPU-last verzeichnet:

Die Speicherauslastung war bis 12:59 angestiegen und fiel erst ca. 8 Stunden später auf einen Tiefstwert um ab da wieder anzuwachsen.

gegen 13 Uhr wurden offenbar größere Datenmengen von der Platte gelesen und kurz drauf gespeichert.


Läuft da ein Backup-Job Rambo?

Ich werde jetzt mal alle Cronjobs durch gehen und auch die Backupaufgaben durch suchen nach auffälligen Sachen in den fraglichen Zeiten.

 

[otto]

Und es geht schon wieder los:


Da laufen php-fpm Prozesse mit mehr Ram als sie nehmen sollten, wie sind schon wieder bei bis zu 160 MB obwohl ein Limit von 128 MB konfiguriert ist.

UID 10013 ist ein FTP-Account einer Domain auf meinem Server.
Man kann die UID in den Nutzernamen wandeln (anzeigen lassen) per:

id -un *ID

Wobei *ID mit der UID ersetzt werden muss, in meinem Fall die 10013 z.B.

0 ist hier der root Nutzer, 10005 ein FTP Account eines Wordpress, 10012 ein FTP Account eines Forum und 10013 der eines FTP Accounts eines anderen größeren Forum.


Ich hab noch immer noch keine so rechte Idee, wo ich weiter ansetzen sollte...
Außer, das ich den Fehler im Bereich einer bestimmten Domain zu suchen habe, die der UID 100013 nämlich.

PHP-FPM ist auch schon wieder fast auf das doppelte binnen 9 Stunden angewachsen, jetzt bei bald 800 Mb



Vorschläge?

 

[Hoffi]

Möglicherweise kam diese im Zusammenhang mit der zunehmenden Auslagerung durch den voll gelaufenen RAM?

Wenn der RAM voll ist, und der Server anfängt zu swappen, braucht das auch ein wenig CPU, könnte damit zusammenhängen, ist aber nur ein wild guess.

Der 7 Tage Rhytmus ist ein wichtiges Indiz. Könnte es evtl. an einem voll laufenden Log liegen, welches nach 7 Tagen geschlossen wird, und dann ist die Performance wieder da?

Dazu müsstest du schauen ob die log-rotation auf Zeit oder Logfile eingestellt ist. Wenn die auf Zeit steht, würde ich das mal versuchen.

 

[mph]

Was gibt es denn, was man mit einem 7-Tage-Rhythmus in Verbindung bringen kann auf deinem Server?

 

[otto]

Da bin ich gerade am suchen. Was mich aber etwas mürbe macht, ist der schon wieder steigende Verbrauch der UID 100013, was eines meiner Foren ist. Und warum steigt das 7 Tage lang und bricht dann zusammen, aber nicht auf das Ausgangsniveau, sondern auf ein jedes mal höheres...

Ich werde weiter suchen...

 

[McAtze]

Der 7-Tage-Rhythmus bei @otto bringt mich auf den Gedanken das er vielleicht die Plesk eigene BackUp Funktion nutzt und extern, eventuell per FTP speichert.
Ich habe zB 6-Tage-Inkrementell und am 7ten Tag komplett.

 

[McAtze]

@otto ich habe es gerade mal bei mir überprüft. Die Grafiken sehen ähnlich aus und der Peak ist immer dann wenn Plesk ein Voll-BackUp durchführt.


Und mein PHP-FPM scheint auch einen Aufwärtstrend zu haben..

 

[otto]

Ja - mir geht es speziell um php-fpm, warum das sich kontinuierlich mehr Arbeitsspeicher krallt.

Bei dir freilich noch alles im Rahmen, aber auch da hielt es sich zunächst auf einem gewissen Niveau und steigt dann auf einmal scheinbar unaufhaltsam weiter an. Und ich wüsste echt gerne warum.
Könnte da auch ein Update schuld sein? Was weiß ich, neue PHP-Version vielleicht?

Laut ps ist bisher aber leichte Entwarnung - da sind gerade im Maximum 92 MB je Prozess des PHP-FPM:

Allerdings wieder ein bestimmtes Forum von mir, was mit höheren Werten glänzt. Ich werde bei der Domain und deren Einstellungen noch mal genauer hinsehen. Allerdings, ist dort auch noch XF 1.5 im Einsatz während der Rest auf XF 2.2.x bzw. Wordpress läuft.

Bei mir gab es mal wieder einen Backup-peak - da muss ich auch mal sehen ob das sich etwas entschärfen lässt:









Werfen wir einen Blick auf den bisher nervenden PHP-FPM:

Etwa gegen 23:00 Uhr im peak mit 874 MB und aktuell wieder bei um die 400 MB. Weiter beobachten. Ich hatte gestern ja auch ein paar kleinere Notfallanpassungen durchgeführt, möglich dass diese sich dann doch noch positiv auswirken.


Ansonsten baut MariaDB wohl den Cache wieder auf, zumindest würde ich das so deuten:


Zeitraum ist jeweils 1 Tag in meinen Stats von zuvor.

@McAtze
Gab es letzte Nacht n Plesk Update? Gestern konnte ich die Grenzwerte im Plesk Advanced Monitoring nicht ändern, weil das speichern mit einer Fehlermeldung quittiert wurde - heut geht das wieder problemlos. Merchwürdig.



Bevor hier aber n Plesk bashing einsetzt - für nur 1-3 Projekte, würde ich es auch nicht mehr nutzen. Aber ich hab aktuell knapp 20 auf dem Server und teils sollen die Kandidaten sich (eingeschränkt) selbst um ihr Hosting kümmern, da ist Plesk extrem hilfreich in den letzten Jahren geworden und kein Vergleich mehr zu einem Plesk 9.x oder davor. Früher musste man vor jedem Update zittern, das ist heut weit entspannter geworden. Perfekt ist Plesk bei Leibe nicht, aber es ist auch nicht (mehr) so mies wie mancher es gern machen möchte.

 

[McAtze]

Gab es letzte Nacht n Plesk Update?

Bei mir mal nicht. Das letzte gab es wohl am 04.05.

 

[otto]

OK, also merkwürdig und mal weiter beobachten.

 

[Masetrix]

Hallo Otto,

gut, dass ich dein Thema hier finde. Ich habe unseren Server letztes WE von Ubuntu 16 auf Ubuntu 18 geupgradet und ein deinem ähnliches Phänomen gehabt.
Der Datenbankserver (MySQL 5.7) "krallte" sich plötzlich 10 GB mehr Arbeitsspeicher und das System ging immer mehr ans auslagern. Schau mal ob da bei dir ein Zusammenhang besteht.

Dann fällt mir auf dass du deine Plesk-PHP-Einstellungen nicht in "
/opt/plesk/php/" machst, sondern im Systemphphpfad. "etc/php/" (...) Das solltest du mal prüfen.

In /opt/plesk/php nimmt man normalerweise die PHP-Einstellungen vor, die die jeweilige PHP-Version in Plesk nutzen soll. Dann, für rein Domain basierte PHP-Einstellungen, sollte man https://deinePleskAdresseOderIP:8443/smb/web/php-settings/id/DeineDomainID verwenden..

 

[otto]

Na ich hab schon länger als das Problem besteht Ubuntu 18.x LTS laufen, und MariaDB hatte ihr letztes größeres Update im zeitigen Frühjahr.
Ich hatte ja zuletzt nach dem Vorfall bisl was angepasst, bisher scheint es damit zu passen, muss aber heut noch mal danach schauen.

Dann fällt mir auf dass du deine Plesk-PHP-Einstellungen nicht in "
/opt/plesk/php/" machst, sondern im Systemphphpfad. "etc/php/" (...) Das solltest du mal prüfen.

Ich weiß, ich hatte/habe bisher auch eher ein PleskUpdate in Verdacht. Deshalb erstmal dort und bisher passt es ja nach den Anpassungen dort. Aber wie es genau dazu kam ist mir noch nicht zweifelsfrei klar.

Die Einzeldomains nutzen ja erstmal die Default Werte - und erst wenn du Domain-Abhängig anderes vorgibst, greifen diese. Das ist schon richtig, aber ich bin tendenziell bequem und wollte nun nicht an knapp 20 Domains gleichzeitig Einzeländerungen vornehmen, daher erstmal nur die Default Werte.

Der FPM ist bisher lieb zu mir:


MySQl hingegen füllt offenbar weiter fleißig den Cache:


Was in Summe allerdings schon wieder nahe an Problemen ist...


da werde ich die Tage mal bisl Feintuning betreiben müssen. Eventuell auch MariaDB bisl einbremsen? Mal sehen.

 

[otto]

Mir scheint MySQL (MariaDB) wohl ursächlich so langsam...




Oder was meint ihr?

Der PHP-FPM ist jedenfalls noch immer im Bereich harmlos:

Seit dem Crash, dicker roter Strich, und einigen Anpassungen der Config ist er entspannt beim Speicherverbrauch.


Hatte das Upgrade auf Xenforo 2 Einfluss?

Die ersten Tage war im Forum noch wenig los nach dem Update, danach hatte ich normale bis bessere Zugriffszahlen, aber nicht weltbewegend.

Kann man sich anzeigen lassen wann man welche Unix Updates durchgeführt hat?
Edit:
Hab es gefunden: var/log/apt/...

Edit 2:
In der fraglichen Zeit:


lagen diese Updates:

Start-Date: 2021-03-19  06:29:28
Upgrade:
 ruby2.5:amd64 (2.5.1-1ubuntu1.7,  2.5.1-1ubuntu1.8)
 libsystemd0:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
 udev:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
 libudev1:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
 libruby2.5:amd64 (2.5.1-1ubuntu1.7, 2.5.1-1ubuntu1.8)
 systemd-sysv:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
 libpam-systemd:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
 systemd:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
 grafana:amd64 (7.4.3, 7.4.5)
 libnss-systemd:amd64 (237-3ubuntu10.44, 237-3ubuntu10.45)
End-Date: 2021-03-19  06:29:59

Start-Date: 2021-03-19  19:06:24
Commandline: apt upgrade
Install:
 linux-headers-4.15.0-139-generic:amd64 (4.15.0-139.143 automatic)
 linux-image-4.15.0-139-generic:amd64 (4.15.0-139.143 automatic)
 linux-headers-4.15.0-139:amd64 (4.15.0-139.143 automatic)
 linux-modules-4.15.0-139-generic:amd64 (4.15.0-139.143 automatic)
 linux-modules-extra-4.15.0-139-generic:amd64 (4.15.0-139.143 automatic)
Upgrade:
 linux-headers-generic:amd64 (4.15.0.135.122, 4.15.0.139.126)
 linux-libc-dev:amd64 (4.15.0-137.141, 4.15.0-139.143)
 linux-image-generic:amd64 (4.15.0.135.122, 4.15.0.139.126)
 linux-generic:amd64 (4.15.0.135.122, 4.15.0.139.126)
End-Date: 2021-03-19  19:07:00

 

[Masetrix]

Moin Otto,

also, das Kernelupdate kannst du ausschließen denn ich habe den HWE Kernel der Version 5 installiert und auch mit dem dasselbe Ergebnis.
Alles in allem scheint sich das Problem auf MySQLzurückführen zu lassen.
Hier werden unter Umständen sehr viele Verbindungen zwar geöffnet, dann aber nicht mehr geschlossen.
MySQL lässt dabei völlig irre Werte zu und Begrenzungen scheinen ignoriert zu werden.
Da muss ich am WE mal intensiver suchen. Ich vermute dass hier zu vieles "persistent" geöffnet wird.
Ebenso scheinen die Werte des /etc/apache2/mods-enabled/mpm_event eine mit ursächliche Rolle zu spielen...

 

[otto]

Ja, MySql (bzw. MariaDB) scheint sich zu viel Speicher zu gönnen und/oder diesen nicht wieder freizugeben.

Was natürlich auch ein Speicherfresser ist, ist ElasticSearch - ich mein man solls ja so konfigurieren (heap size) dass es sich maximal 50% vom Speicher gönnen darf, aber wenn ich mal mit htop drauf schaue... komm ich mit den Werten noch nicht ganz klar:


Nach dieser (recht guten) Erläuterungen zu htop:

würde ich sagen dass Elastic Search sich aktuell 32 GB (RES) bzw. 52,2 % (MEM) gönnt, das würde ganz gut passen zu den knapp 37 GB verwendet.

In Plesk Obsidian schaut heut so aus in der 7 Tage Serverinzidenz :

Der Apache raucht Friedenspfeife...

Der Datenbankserver hingegen verhält sich weiterhin wie Ulli Höneß bei Willi Wankas Schokoladenfabrik:

Mal kurz auf 30 Tage Sicht:

Da geht noch was...

Von Seiten Auslagerung schauts auch gut aus:


Weiter beobachten...