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

  • 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
    1. total used free shared buff/cache available
    2. Mem: 12307328 10438944 261404 10276 1606980 1594012
    3. Swap: 1492988 1340752 152236
    4. total used free shared buff/cache available
    5. Mem: 12307328 10439688 1673576 10276 194064 1612204
    6. Swap: 1492988 1340744 152244


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

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


    Beenden von amavis und clam-daemon:

    Code
    1. total used free shared buff/cache available
    2. Mem: 12307328 9254588 2766640 11608 286100 2790976
    3. Swap: 1492988 362744 1130244
    4. total used free shared buff/cache available
    5. Mem: 12307328 9254436 2968544 11608 84348 2851660
    6. 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.

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