Arbeitsspeicher nach Zombieload Update voll

  • Seit der Zombieload Wartung ist der RAM meines Servers fast voll. Wenn ich Dienste, welche vorher dauerhaft liefen starte, wird dann auch der Swapspace bis zum Rand befüllt.

    Die laufenden Prozesse verbrauchen aber bei weitem nicht soviel Arbeitsspeicher, wie in Nutzung ist.

    Die Datei im Anhang besteht aus der Ausgabe von "free" und die Prozessliste, sortiert nach Arbeitsspeicher Nutzung. Erzeugt mit: ps aux  | awk '{print $6/1024  " MB\t\t" $2 "\t" $11}'  | sort -n


    Der Helpdesk kann mir leider nicht helfen, da das Problem nicht im Rettungssystem auftritt...


    Produkt: Root-Server L SSD v6 6MFestplatte: 240 GB SSD Performance

    Arbeitsspeicher DDR 4 ECC: 12 GB

    Prozessorkerne: 4 dediziert

    Prozessor: Intel® Xeon® E5-26xxV3

  • (Bevor jetzt jeder die erste Spalte mit dem Speicherverbrauch addiert: Die Summe ist kleiner als 3GB.)

    • Welches Betriebssystem, ggf. welcher Kernel ist im Einsatz?
    • Gab es ein Update einer/mehrerer Komponenten direkt vor/nach dem Neustart (viele Administratoren nutzen die Gelegenheit), d.h. ist eine direkte Vergleichbarkeit eines neu gebooteten Systems einmal vor, einmal nach der Wartung gegeben? (Ich habe just dieser Tage u.a. ein Docker-Update gesehen)
    • Falls es ein Linux-System ist: Liefert die erzwungene Freigabe aller Puffer usw. (hier erläutert!) kurzzeitig ein deutlich verbessertes Bild?
    Code
    free && sync && echo 3 > /proc/sys/vm/drop_caches && free
    • Wenn man selektiv alle Docker-Prozesse, danach alle Mail-Subsysteme stoppt, wird es dann schlagartig besser (ggf. mit obengenannter Sequenz verifizieren)?

    Anmerkung: Die Swap-Größe erscheint mir mit <15% des Hauptspeichers zu unterdimensioniert, um sie sinnvoll nutzen zu können – wenn der Server wirklich zeitweilig einen großen Speicherbedarf hat, bringen 1,5GB nicht viel bei 12GB Hauptspeicher. Würde ich – nach Klärung o.g. Problems – (deutlich) vergrößern oder grundsätzlich abschalten...

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Es handelt sich um ein Debian 9.9

    Kernel 4.9.0-9-amd64

    Ich spiele fast täglich Paketupdates ein. Gestern wurden noch keine Updates installiert.


    Hier die Ausgabe der Sequenz mit dem Löschen des Caches:

    Code
    total        used        free      shared  buff/cache   available
    Mem:       12307328    10438944      261404       10276     1606980     1594012
    Swap:       1492988     1340752      152236
                  total        used        free      shared  buff/cache   available
    Mem:       12307328    10439688     1673576       10276      194064     1612204
    Swap:       1492988     1340744      152244


    Anschließend wurde der ganze Docker Daemon beendet (+Cache Leerung):

    Code
    total        used        free      shared  buff/cache   available
    Mem:       12307328     9410024     2807744       10336       89560     2694024
    Swap:       1492988      463112     1029876


    Beenden von amavis und clam-daemon:

    Code
    total        used        free      shared  buff/cache   available
    Mem:       12307328     9254588     2766640       11608      286100     2790976
    Swap:       1492988      362744     1130244
                  total        used        free      shared  buff/cache   available
    Mem:       12307328     9254436     2968544       11608       84348     2851660
    Swap:       1492988      362744     1130244


    Anschließend gestaltet sich die Prozessliste (auf eine Seite gekürzt) so:

  • (Eigennotiz: Immer zur Kontrolle die genannten Befehle zur Datenermittlung lokal gegenprüfen.)


    Das Problem hier ist die unvollständige Ausgabe von "ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n" – in der sechsten Spalte steht nämlich nur der von einem Prozess verwendete physische Speicher ("RES"), insbesondere die Spalte davor mit dem virtuellen Speicher ("VIR") ist jedoch ebenfalls zu berücksichtigen (genauso wie die Spalte 7 danach ("SHR")). Eine Erläuterung der Werte findet sich hier.


    Summiere ich auf dem eigenen System den physischen Speicherbedarf, lande ich bei 11GB, [h]top – htop ist hier übrigens komfortabler, weil man die Ausgabe sortieren/filtern kann und an zusätzliche Parameter kommt – nennt mir aber inklusive der anderen Speicherartbedarfe eine Auslastung von >25GB der 32GB RAM.


    Wenn die Ausgabe von free/top vor dem Patchen des Hostsystems wirklich deutlich niedriger lag, würde ich vermuten, dass mit einem Systemupdate einfach ein größerer Hunger nach virtuellem Speicher durch eine/mehrere Komponenten "entstand". Dies läßt sich nur rückverfolgen, indem man die größten "Bedarfsanmelder" identifiziert und in der apt/dpkg history (/var/log/apt/history.log bzw. /var/log/dpkg.log) eine ggf. kürzlich eingespielte neue Version unter die Lupe genommen wird.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • In einem anderen Thread wurde genau dieses Verhalten bemängelt: https://forum.netcup.de/admini…h-am-6-7-2019/#post122049

    Der TE nutzt laut eigener Aussage aber noch Debian 9.9; o.g. Thread diskutiert ja Änderungen, die mit Debian 10 kommen:

    Es handelt sich um ein Debian 9.9

    Kernel 4.9.0-9-amd64

    Kann natürlich gut sein, dass mit Freigabe von Debian 10 auch ein paar Backports in 9.9er-Repositories landeten… habe ich selbst bislang nicht nachverfolgt, da ich bis auf wenige Ausnahmen (in Containern) derzeit nur Ubuntu einsetze.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing