Server/Hosting PHP-FPM mit teils exorbitant hohem Speicherverbrauch

Dieses Thema im Forum "Technik und Co." wurde erstellt von otto, 22. Mai 2021.

  1. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Hallo,

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



    upload_2021-5-22_13-28-8.png
    upload_2021-5-22_13-28-37.png
    Detailierter:
    upload_2021-5-22_13-29-8.png
    upload_2021-5-22_13-29-25.png


    Pfeil 1 = Beginn, Ausfall
    Pfeil 2 = Reboot, erst einmal alles OK
    upload_2021-5-22_11-59-10.png
    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:
    upload_2021-5-22_11-49-54.png
    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:
    upload_2021-5-22_12-49-0.png
    aktuell schwankt das Maximum um die 95-99 MB jeweils ...
    und insgesamt:
    upload_2021-5-22_12-51-0.png
    etwas detailierter:
    upload_2021-5-22_12-51-39.png
    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:
    upload_2021-5-22_12-54-1.png

    Letzte 30 Tage:
    upload_2021-5-22_12-54-32.png
    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:
    upload_2021-5-22_12-38-10.png

    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? :)
     
    Zuletzt bearbeitet: 22. Mai 2021
  2. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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
     
    Zuletzt bearbeitet: 22. Mai 2021
  3. otto

    otto Bekanntes Mitglied Lizenzinhaber

    @McAtze
    Könntest das hier bitte zu Technik und co schieben? Dankeschön. :)
     
    McAtze gefällt das.
  4. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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 gefällt das.
  5. Hoffi

    Hoffi !important Lizenzinhaber

    Danke für den Bericht. Ich bin gespannt was bei rauskommt.
     
    Masetrix gefällt das.
  6. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Was mich stutzig macht, ist auch die deutlich markant angestiegene CPU Last kurz vorm K.O.:
    upload_2021-5-22_19-25-24.png
    upload_2021-5-22_19-4-40.png
    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:
    upload_2021-5-22_19-9-50.png
    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:
    upload_2021-5-22_19-11-9.png
    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:
    upload_2021-5-22_19-27-7.png
    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:
    upload_2021-5-22_19-30-40.png
    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:
    upload_2021-5-22_19-33-39.png
    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.
    upload_2021-5-22_19-37-58.png

    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.
     
  7. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Und es geht schon wieder los:
    upload_2021-5-22_19-41-49.png

    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:
    Code (Text):
    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
    upload_2021-5-22_19-59-20.png


    Vorschläge?
     
    Zuletzt bearbeitet: 22. Mai 2021
  8. Hoffi

    Hoffi !important Lizenzinhaber

    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.
     
    otto gefällt das.
  9. mph

    mph Bekanntes Mitglied Lizenzinhaber

    Was gibt es denn, was man mit einem 7-Tage-Rhythmus in Verbindung bringen kann auf deinem Server?
     
    otto gefällt das.
  10. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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...
     
  11. McAtze

    McAtze Innendienst Lizenzinhaber

    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.

    Bildschirmfoto 2021-05-22 um 21.42.45.png Bildschirmfoto 2021-05-22 um 21.40.59.png
     
  12. McAtze

    McAtze Innendienst Lizenzinhaber

    @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.
    Bildschirmfoto 2021-05-22 um 21.49.40.png

    Und mein PHP-FPM scheint auch einen Aufwärtstrend zu haben.. :eek:
    Bildschirmfoto 2021-05-22 um 21.48.47.png
     
  13. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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:
    upload_2021-5-23_9-30-58.png
    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:
    upload_2021-5-23_9-33-49.png
    upload_2021-5-23_9-34-31.png
    upload_2021-5-23_9-34-52.png
    upload_2021-5-23_9-35-8.png
    upload_2021-5-23_9-42-4.png




    Werfen wir einen Blick auf den bisher nervenden PHP-FPM:
    upload_2021-5-23_9-36-13.png
    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:
    upload_2021-5-23_9-39-4.png

    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. :) ;)
     
  14. McAtze

    McAtze Innendienst Lizenzinhaber

    Bei mir mal nicht. Das letzte gab es wohl am 04.05.
     
    otto gefällt das.
  15. otto

    otto Bekanntes Mitglied Lizenzinhaber

    OK, also merkwürdig und mal weiter beobachten. :D ;)
     
  16. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    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..
     
    Zuletzt bearbeitet: 25. Mai 2021
  17. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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. :)

    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:
    upload_2021-5-25_20-15-19.png

    MySQl hingegen füllt offenbar weiter fleißig den Cache:
    upload_2021-5-25_20-16-23.png

    Was in Summe allerdings schon wieder nahe an Problemen ist... ;)
    upload_2021-5-25_20-17-20.png

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

    otto Bekanntes Mitglied Lizenzinhaber

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

    upload_2021-5-26_8-14-53.png
    upload_2021-5-26_8-16-34.png

    Oder was meint ihr?

    Der PHP-FPM ist jedenfalls noch immer im Bereich harmlos:
    upload_2021-5-26_8-17-29.png
    Seit dem Crash, dicker roter Strich, und einigen Anpassungen der Config ist er entspannt beim Speicherverbrauch.


    Hatte das Upgrade auf Xenforo 2 Einfluss?
    upload_2021-5-26_8-26-25.png
    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:
    upload_2021-5-26_9-2-20.png

    lagen diese Updates:
    Code (Text):

    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
     
    Zuletzt bearbeitet: 26. Mai 2021
  19. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    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...
     
  20. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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:
    upload_2021-5-27_9-39-28.png

    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 :D ;) :
    upload_2021-5-27_9-43-48.png
    Der Apache raucht Friedenspfeife...
    upload_2021-5-27_9-45-32.png
    Der Datenbankserver hingegen verhält sich weiterhin wie Ulli Höneß bei Willi Wankas Schokoladenfabrik:
    upload_2021-5-27_9-46-41.png
    Mal kurz auf 30 Tage Sicht:
    upload_2021-5-27_9-47-27.png
    Da geht noch was... ;)

    Von Seiten Auslagerung schauts auch gut aus:
    upload_2021-5-27_9-58-38.png

    Weiter beobachten... :)
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden