Server/Hosting PHP-FPM mit teils exorbitant hohem Speicherverbrauch

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

  1. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    otto gefällt das.
  2. otto

    otto Bekanntes Mitglied Lizenzinhaber

    @Masetrix
    Auch wenn das MySQLTuner Script eigentlich veraltet ist - was schlägt das denn vor? Lass das doch mal laufen und poste was das zu deiner MySQL Config sagt.

    Ich würde beim Umgang mit Plesk vorsicht walten lassen. Das aktuellen Obsidian läuft sehr stabil, aber wenn ich eines weiß, dann das man Plesk nicht all zu sehr ins Handwerk pfuschen sollte.
    Weiterhin würde ich zu dem Thema mal ein Thema im Plesk Support Forum eröffnen, die helfen einem da zu solchen Themen meist recht kompetent.

    Ne Last von über 1 würde ich nicht so doll finden, als Dauerzustand. Klar darf der mal über 1 gehen, aber das sollte nicht dauerhaft der Fall sein - denn was soll dann bei echten Lastspitzen passieren? ;)

    In welchem Last-Szenario? Also wie ausgelastet ist in dem Moment dein Server? 90% würde ich als Speicherauslastung ebenfalls nicht als Dauerzustand sehen wollen, weil dann kaum noch Luft für Lastspitzen oder Attacken bleibt.
     
  3. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Gesagt, getan :D
    Code (Text):

    General recommendations:
        Control error line(s) into /var/log/mysql/error.log file
        MySQL was started within the last 24 hours - recommendations may be inaccurate
        We will suggest raising the 'join_buffer_size' until JOINs not using indexes are found.
                 See https://dev.mysql.com/doc/internals/en/join-buffer-size.html
                 (specially the conclusions at the bottom of the page).
        Temporary table size is already large - reduce result set size
        Reduce your SELECT DISTINCT queries without LIMIT clauses
        Increase table_open_cache gradually to avoid file descriptor limits
        Read this before increasing table_open_cache over 64: https://bit.ly/2Fulv7r
        Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optimizing-table_open_cache/
        This is MyISAM only table_cache scalability problem, InnoDB not affected.
        See more details here: https://bugs.mysql.com/bug.php?id=49177
        This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
        Beware that open_files_limit (1024000) variable
        should be greater than table_open_cache (2500)
    Variables to adjust:
        join_buffer_size (> 1.0M, or always use indexes with JOINs)
        table_open_cache (> 2500)
        innodb_buffer_pool_size (>= 12.0G) if possible.
     
    Die InnoDB_BufferPoolSize habe ich momentan auf 8 GB reduziert, das bringt erstmal Luft im Ram sodass nun nur noch 20GB insgesamt genutzt werden. Die Joinbuffersize setze ich nicht höher, weil das per Client zu Buche schlägt und keine messbare Verbesserung bringt.

    Dass der MySQLTuner veraltet ist oder sein soll ist für meine Zwecke nicht relevant denn er zeigt das mir wichtige an Werten an und dient somit als Richtschnur.
    Da stimme ich dir vollstens zu, daher auch mein Faible für "Standards". Aus dieser Sicht gesehen hat es mich ja gerade verwundert, dass du PHP einmal von der OS-Ebene her und andererseits die von Plesk genutzten verwendest.

    Würde ich auch wenn mein Englsch zulassen würde die Probleme Umfangreich und Detailiert, sauber im Englischen darzustellen. Un wenn ich sehe was die Übersetzungstools so aus dem machen was ich eigentlich sagen wollte. :(

     
  4. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Öhm... lass den Server erstmal mindestens 48h laufen, ehe du das Script laufen lässt - sonst schlägt das gerne mal wirre Sachen vor. ;)

    Aber ich glaub hier hat Atze noch nicht sauber aufgeräumt - jedenfalls hat das MySQL Problem ja eher wenig mit meinem Eingangsproblem zu tun wo es um php-fpm ging.

    Atze hat die Themen schon geteilt, @Masetrix bitte im richtigen weiter schreiben - denn quer Beet bringt ja am Ende keinem was. :)
     
  5. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Da irrst du dich.
    PHP-FPM, MySql und der Apache müssen sauber durch konfiguriert und aufeinander abgestimmt sein. Passt das wegen unpassender Einstellungen an einer Stelle nicht kommt es zwangsläufig zu Flaschenhälsen, hohem Speicherverbrauch, (...)
    Da sich bei mir das Problem (Speicherverbrauch) eher von der MySQL Seite her zeigte habe ich mich auf das Thema gemeldet.
    Inzwischen habe ich auch einen Durchbruch beim Apachen erzielt. Ich war gedanklich noch zu sehr auf mod_prefork getrimmt was die Konfiguration des mpm_event angeht.
    Man muss die Verwendung des mpm_even an die Anzahl der Cores anpassen und schon flutscht es sowohl beim Load (nachdem die Caches wieder gefüllt sind) als auch bei der Performance die der Apache im Web bringt.

    Pagespeed zeigt nun auch eine schnellere Reaktionszeit...

    https://www.liquidweb.com/kb/apache-performance-tuning-mpm-directives/
    Bei 8 Cores habe ich nun folgende Konfig, von der aus ich arbeiten kann, den php-fpm und MySQL entsprechend zu optimieren bzw. der neuen Situation anzupassen.

    /etc/apache2/mods-available/mpm_event.conf
    Code (Text):

    <IfModule mpm_event_module>
            ServerLimit                16
            StartServers               2
            MinSpareThreads          400
            MaxSpareThreads          400
            ThreadLimit               64
            ThreadsPerChild           50
            MaxRequestWorkers        400
           MaxConnectionsPerChild  10000
    </IfModule>
     
     
    Zuletzt bearbeitet: 5. Juni 2021
  6. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Sodele @otto,

    dein Problem hängt direkt mit dem von mir erkannten zusammen.
    Auch bei mir nutzt PHP-FPM (zu) viel Speicher, was aber letztlich durch den Apachen verursacht wird, der zu viele "Verbindungen" öffnen kann, ohne diese wieder zu schließen. Das hat, zumindest in meinem Setup, auch Auswirkungen auf ein zu großzügig konfiguriertes MySQL. Vermutlich, weil bei dir noch Nginx dazwischen arbeitet, wirkt sich die Ursache bei dir etwas anders aus.

    Beiden gemeinsam ist dass des Nachts, wenn Backups laufen und Plesk spätestens am morgen seine Wartungsaufgaben ausführt, der Speicherverbrauch exorbitant in die Höhe schnellt.

    Ursache bei mir ist nun dass Plesk (wo und wie genau habe ich noch nicht exakt eruiert) IMMER 2 neue (Apache)Server- und Mysqlverbindungen öffnet, die nachfolgend auch nicht mehr geschlossen werden und damit den Speicher füllen.

    Je nach Setup des Apachen und damit in Verbindung stehend natürlich auch des php-fpm, potenziert sich dabei der Speicherverbrauch dynamisch, was im Worstcase zum Stillstand des Servers führen kann.
    Da du das Gespann Apache/Nginx nutzt kann es natürlich durchaus sein, dass sich das Problem bei dir weniger bei Mysql, sondern mehr beim php-fpm zeigt weil bei mir der php-fpm ungenutzte Verbindungen sehr früh schließt (~Timeouts), dafür aber Mysql sehr viel im RAM hält.
    Durch die kürzeren Timouts bei mir erklärt sich auch der höhere Load weil Apache und php-fpm mehr "spawnen" müssen/mussten.

    Seit letzter Nacht hab ich nun mein Problem soweit unter Kontrolle dass das System performant läuft, der Load in akzeptablen Grenzen ist und der Speicher NUR noch (geringfügig) in den swap überläuft wenn Plesk seine Backup- und sonstigen morgendlichen Wartungsroutinen durchlaufen hat.

    Jetzt kann ich mich an das eigentlich verursachende Problem machen und Plesk tracken um dem Support eventuell genaueres - und vor allem nachvollziehbares - berichten zu können.
     
    otto gefällt das.
  7. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Hier mal aktuelle Statistiken rund um Apache PHP-FPM und MySQL:

    20 Tage Überblick
    upload_2021-6-6_9-26-41.png
    upload_2021-6-6_9-29-30.png
    upload_2021-6-6_9-34-32.png


    Und auf längere 90 Tage Sicht:
    upload_2021-6-6_9-27-48.png
    upload_2021-6-6_9-28-43.png
    upload_2021-6-6_9-35-4.png

    Im Moment schaut es bei mir nicht nach neuem Ärger aus, die Auslagerung wird tendenziell immer weniger genutzt.
    Ich bin daher noch am beobachten der Lage, ehe ich da weiter eingreife. Ich hatte ja damals am Tag Null ein paar kleinere Anpassungen an der Apache Konfiguration gemacht, das wollte ich nun erstmal beobachten wie diese sich auswirken. Gleichwohl wird sicher auch MariaDB noch etwas Feinschliff benötigen.

    Aktuell setze ich jetzt noch die Warnschwelle für die Auslagerung herab, auf 2 GB - das sollte mir im worst case genug Zeit geben zu reagieren.
     
    Masetrix gefällt das.
  8. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Diese schönen Grafiken sind beneidenswert.
    Ich bin aber so ein alter "Dosler" daher sagt mir ein top in der Commandozeile mit nachfolgendem M an der Tastatur weit mehr wer gerade den meisten Speicher frist. Dabei sieht man auch gleich Menge und den Nutzer... Hier spielen die Nutzer "www-data" und "php-fpm" nebst "mysql" hier eine gewichtige Rolle.

    BtW.
    Dein Speicherverbrauch durch den SQL-Server ist beneidenswert niedrig. Ich halte derlei lieber im RAM und erspare mir so Nginx, Redis und Konsorten. ;)
     
  9. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Mag für einzel-Projekte prinzipiell der bessere Weg sein. Auf Meinem Server laufen Xenforo, Shopware, Wordpress und einige andere die alle samt unterschiedliche Ansprüche haben. Das über die Konsole zu managen, fehlt mir die Zeit und ist mir deshalb zu fehlerträchtig auch wenn ich die Konsole einer Sehnenscheidenentzündung immer vorziehen werde. ;)

    Oder kurz um - alles im Ram zu halten würde hier erheblich mehr Speicher bedeuten, den hab ich aber nicht. Nginx+Redis bringen einiges an Tempo ohne das System gar zu sehr zu belasten und ohne Elasticsearch möchte ich auch nicht mehr müssen. ;)

    Aber den top Screenshot kannst du gern haben und da sieht man auch, das bei mir eben Elasticsearch einen "gewissen" Einfluss auf den Speicherverbrauch hat.
    upload_2021-6-6_11-19-31.png

    PS. Grafna kann man maasiv ausweiten und hat dann die totale Überwachung des Servers, wenn man wollte.
     
  10. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    In der Tat, da es aber kein Standard ist - wie gesagt ich möchte so nah wie möglich am Standard arbeiten - kommt mit derlei nicht auf dat Maschinchen. ;)
    Wenn ich den Rambedarf deines Elasticsearch so ansehe kann ich auch darauf gerne Verzichten da man auch mit Standard MySQL gute Ergebnisse erzielen kann. Für die 10 Projekte hier reicht es ewig.

    Einzig der nicht nachvollziehbare Speicherbedarf von MySQL macht mir Probleme. der PHP-FPM ist unter Kontrolle.
    Ich werde mal probieren ob MariaDB 10.x Besserung bringt, immerhin ist das ja der eigentliche Standard bei Ubuntu 18.05 LTS.

    Hier, bei mir sieht das so aus...
    upload_2021-6-11_16-38-11.png

    Die Forendatenbank ist hierbei mit rund 8 GB das Größte und die will ich im Speicher halten weil das im Zusammenhang mit SSD ein unschlagbares SpeedGespann ist.

    Aber zurück...
    Was ist denn an deinen Projekten so umfangreich dass es mit kaum Datenbank auskommt, dafür aber irrsinnig viel ~PHP abarbeiten muss? Ist da viel Grafik im Spiel? Viele Addons?
     
    Zuletzt bearbeitet: 11. Juni 2021
  11. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Nope - das schaffst du mit Standard MySQL definitiv nicht mit der Performance. Und da hier auch ein Shop dran hängt, kann ich mir "zu langsam" nicht leisten. ;)

    An DBs hab ich in Summe an die 10 GB aktuell, Tendenz steigend und ich kann mir nicht den ganzen Speicher mit der DB blockieren bei Grafik-lastigen Seiten.

    Die Suche über ES ist um Lichtjahre schneller und komfortabler als die Standard-Suche. Mit ES hat man gefühlt sofort das Ergebnis, auch bei nur 2 Zeichen als Suchbegriff. Und mal ehrlich, ES ist im Bereich Suche am Ende auch schon sowas wie Standard - ist halt immer eine Frage des Blickwinkels. ;)

    3 Bildlastige Xenforos, 1 Bildlastiger Shop, mehrere Wordpress, Mehrere Datenbanken mit eigenen Frontends. MySQL läuft bei mir aktuell flüssig genug, zumal die DBs auf einer SSD liegen und ich hoffe irgendwann auf einer noch schnelleren "Platte" a la NVME z.B.. Daher reicht mir eine gewisse Cache-Größe aus. Es werden viele dynamische Abfragen generiert und die Suche ist Elementar für den Großteil meiner Seiten
     
  12. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Dann würde ich mir nicht die Zeit mit der Suche nach einem "gierigen" PHP-FPM verballern. ;)
    Dedicated Root Server Hosting - Hetzner Online GmbH
    upload_2021-6-12_10-45-43.png
     
  13. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Dir ist aber auch klar, dass der dann mit mindestens 125,59 € zu Buche schlägt je Monat. ;)
    Serverstandort DE, Plesk Web Pro, zusätzlicher Baclupspace nötig (nur 100 GB inkl. bei 2x2 TB ?) 12 Kerne? Ich bekomme ja meine 8 noch nicht mal ausgelastet solange das Thema Ram/Cache sich friedlich benimmt. :D ;)

    Aktuell komm ich doch noch gut mit meinem Strato root Server klar, und zahle erheblich weniger.
    z.B. der hier würde mir schon gefallen und locker reichen:
    Linux Root Server mieten für maximale Leistung | STRATO
    upload_2021-6-12_11-43-53.png
    Da ist Plesk Web Pro dabei, 1GB Uplink (unlimited), 1TB Backup Space (Traffic frei)
    Für 25 € mehr im Monat könnte man ProNet VLAN dazu buchen und so die ungenutzte 2. Netzwerkkarte fürs Backup nutzen, was dann der Verfügbarkeit dienlich sein sollte.

    Eventuell würde es ja auch Sinn machen Mittelfristig auf 2 Server zu setzen. Einen mit MVMe für die Datenbank und den Zweiten mit großer SSD und viel Ram als Dateigrab. Sowas in kleiner und langsamer hatte ich mal vor Jahren, aber damals wars noch mit Plesk 9 ein Graus. Heute mit Obsidian wäre das ungleich entspannter zu händeln.

    ich würde meinen, bei NVMe für die DB kann man sich womöglich einiges an Ram sparen, wenn da ne aktuelle NVMe drin ist, oder gar später mal ne V2, dann ist der Ram kaum noch merklich schneller. Merkt man am PC ja schon, der schafft es im Regelbetrieb ja auch nicht ne NVMe ansatzweise auszulasten. OK, so ein Server mit X Domains hat erheblich mehr Zugriffe, aber dennoch, ich denke mit den NVMe's wird der Hang zu viel Ram womöglich weniger Einfluss haben können.
     
    Masetrix gefällt das.
  14. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Zuletzt bearbeitet: 12. Juni 2021
    otto gefällt das.
  15. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Noch eine Frage, du nutzt auch nicht cgroups oder den cgroupsmanager von Plesk um Ressourcen zu begrenzen?


    Nachtrag:

    Ab Ubunti 18.x scheinen die früheren "Begrenzer" nicht mehr zu greifen. Man MUSS Cgroups einsetzen um das System im Zaum zu halten. Bei mir konnte sich z.B. MySql 160 GB Speicher greifen, obwohl mit Swap nur 48 GB zur Verfügung stehen.

    Eruieren kannst du das mit

    # sudo service mysql status
    # sudo service apache2 status

    ...
    genauer:
    # sudo systemctl show -p CPUShares,MemoryLimit apache2
    # sudo systemctl show -p CPUShares,MemoryLimit mysql
    ...
    Begrenzen... (Hier mysql auf ~20 anstelle von 160G)
    sudo systemctl set-property mysql MemoryLimit=20000000000
    ...
    Aktivieren der Einstellungen (im laufenden System)
    # sudo systemctl daemon-reload

    PHP-FPM begrenzt man über den Apachen bzw. Nginx...

    Man hat ja sonst nichts zu tun.... ;)
     
    Zuletzt bearbeitet: 13. Juni 2021
  16. otto

    otto Bekanntes Mitglied Lizenzinhaber

    upload_2021-6-13_10-55-52.png

    Bei "systemctl show -p CPUShares,MemoryLimit mysql" das gleiche Ergebnis.

    Ich beobachte erstmal weiterhin... denn bisher läuft er geschmeidig dahin: (roter Strich war der Vorfall)
    upload_2021-6-13_11-0-55.png
    upload_2021-6-13_11-1-50.png
    upload_2021-6-13_11-2-22.png
    upload_2021-6-13_11-3-11.png
    upload_2021-6-13_11-4-3.png
    upload_2021-6-13_11-4-32.png


    Akuten Handlungsbedarf sehe ich jetzt gerade nicht, aber ich schau weiter tgl. wie es sich entwickelt.
     
  17. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Ja das sieht gut aus. Ich werde dann mal weiter mit cgroups experimentieren denn fast alle Grenzwerte in Ubuntu 18.x sind auf infinite/unendlich gesetzt. Wie der Vorfall hier mit MySql gezeigt hat ist das durchaus ernst gemeint und umgeht - wie und warum auch immer - plötzlich alle von der Anwendung bisher genutzten Grenzen. So konnte ich mich bisher darauf verlassen, dass MySql die maximalen Werte für Speichernutzung nur minimal überschritten hat.

    Das gilt nun offensichtlich nicht mehr und als gebranntes Kind will ich das sicher begrenzen bevor der Server unerreichbar wird, wenn mal wieder die Sichheitslückenbots aufs System "einprasseln".
    Sobald ich die ersten, realen Testergebnisse habe melde ich mich dahingehend wieder. :D

    Btw. Plesk hat auch einen "CG-Manager" im Angebot.
    Da der aber monatlich fast genauso teuer ist wie Plesk (30 Domains),
    mache ich mir - sobald ich mich tiefer in die CGroupsfunktionsweise eingearbeitet habe - ein eigenes Script und spare mir so die 5 Euro monatlich zusätzlich. Das Ganze gibt es dann hier als Freeware.
     
    otto gefällt das.
  18. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Also meiner war zu jeder Zeit trotz Web-Ausfall per Plesk und FTP/SSH erreichbar - das hatte mich auch schon gewundert wie der Apache abkacken kann und Plesk unbeeindruckt flott weiter läuft.

    Könnte es sein dass ich den CG-Manager in der Web Pro Edition von Strato schon inkl. habe, also nur noch installieren muss?
    upload_2021-6-13_22-14-36.png
    Zumindest steht er mir bei den Updates als Option zur Verfügung und dort ist normal nur was auch installiert werden könnte.
     
  19. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    Plesk nutzt seine eigenes PHP (7.3) und eine eigene Instanz von Nginx. Daher ist es auch noch erreichbar, wenn das normale Web bereits die Flügel gestreckt hat. Wenn man dem SSHd dann noch die Priorität z.B. von 20 (Standard) auf 15 "heraufgesetzt" hat ist das System auch noch erreichbar wenn alles andere "steht".

    Die Cgroupsinstallation die du oben anzeigst habe ich auch, und auch installiert. Das ist aber nur die halbe Miete, du brauchst dazu noch ein kostenpflichtiges Pleskaddon, den CGroupsManager, damit du damit bequem alle Plesksachen per ACP konfigurieren kannst.

    Ansonsten, wenn du nur die "halbe Miete" installierst musst du das u.A. mit den Befehlen steuern, die ich weiter oben erwähnt habe und natürlich Dokumentation wälzen. ;)

    Ich finde CGroups schon ganz gut weil ich heute erleben durfte dass man damit auch zwischen Auslagerungsspeicher(Virt.) und RAM-Nutzung(Res.) - je Anwendung - unterscheiden kann. Mein MySql hält sich inzwischen daran dass es ganz brav nur maximal 23G (Res) normales RAM nutzt, geht ihm dabei die Puste aus, nutzt es den Auslagerungsspeicher und lässt die restlichen 9G echten Speicher (RAM) frei. Das eröffnet völlig neue Möglichkeiten, wenn man bedenkt dass SSD fast genauso schnell ist wie normales RAM. Dazu habe ich noch eingestellt dass MySQL nur max 6 von 8 CPUKernen nutzen darf. Im Fall des Falles hat das System also noch 2 Kerne mit 4 Threads zur Verfügung. Das muss ich jetzt noch feiner granulieren indem alle anderen Beteiligten einbezogen und aufeinander abgestimmt werden.

    Bis auf den Umstand, dass da ab sofort noch eine zu konfigurierende Instanz dazukommt bin ich aber mehr erfreut über die sich bietenden neuen Möglichkeiten.

    Klar, einen dedizierten Datenbankserver möchte man so nicht konfiguriert wissen, aber für meinen Zweck, für Lastspitzen, warum nicht einfach eine 2. 256GB-SSD rein und ins Swap (Virt.) mounten :D
     
    Zuletzt bearbeitet: 14. Juni 2021
  20. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Ich weiß - es ging ja drum, das der Speicher voll lief. Und da gibts ja nur den einen im Server. Aber möglich, das Plesk da Bereiche fix reserviert, wäre denkbar.

    Ok, ja, die extension wäre schon nice to have... in der billigsten Variante 5.45 €/Jahr - da wäre fast schon das Plesk Hosting Pack interessant, was 21,85 € im Monat kostet und gleich einiges mehr böte.
     
  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