Monatsrückblick Juli / August 2026 ist online!

[Dr. Bakterius]

@Homoran sagte:

Gegen 03:00+
Available bleibt hoch, steigt sogar an, aber free geht gegen 0.

BackItUp vielleicht? Oder was läuft sonst so um 03:00?

[Michael Schmitt]

Hast du mal ein iob diag ? Vielleicht sehen die Profis ja dort was.

[Homoran]

@Dr.-Bakterius sagte:

BackItUp vielleicht?

Möglich!
Aber der Speicher wird anscheinend nicht mehr freigegeben!
Erst 5h später

Und der memAvailable steugt nur um ca. 300-400MB während der Free um 2.5 GB zurück geht.

Aber da laufen wir wahrscheinlich in die nächste Sackgasse.
Während des backups ist iob in den letzten Tagen noch nie beendet worden.

[paul53]

@Homoran [sagte]:
Aber der Speicher wird anscheinend nicht mehr freigegeben!
Erst 5h später

Der interne Puffer des OS wird nicht gleich wieder freigegeben. Vermutlich wird eine Warteschlange aufgebaut, da die IO-Operationen nicht schnell genug erfolgen.

[Michael Schmitt]

sollte swap da nicht auch was von abfangen ? Wie sieht es da aus ?

[Homoran]

@paul53 sagte:

Vermutlich wird eine Warteschlange aufgebaut, da die IO-Operationen nicht schnell genug erfolgen.

Hmm, das klingt schon plausibel!
..undcwenn dann bei nur noch 200MB memFree noch etwas den Speicher frisst.....

Mir ging es ja auch nur um die Diskusdion mit @oliverio dass der Speicherschwund am memAvailable hätte zu sehen sein müssen, während ich es nur am memFree und dort sehr deutlich sah.

Zusätzlich war der DP system.host...freemem, den ich geloggt hatte leider auch memAvailable

[Homoran]

@Michael-Schmitt sagte:

sollte swap da nicht auch was von abfangen

WENN es in den I/O Vorgängen klemmt, dürfte da auch die Auslagerung zu spät kommen

[Homoran]

@paul53
Möglicherweise habe ich eine Denkblockade.
Wenn

Homoran sagte:

der memAvailable steigt nur um ca. 300-400MB während der Free um 2.5 GB zurück geht

würde das für mich bedeuten, dass irgendein Prozess 2000MB fest verbraucht oder reserviert.

Ersteres kann ich nirgendwo feststellen, zweiteres wüsste ich nicht wie.

Davon ab klingen plötzliche zusätzliche 2GB für einen Prozess schon sehr viel.

[paul53]

@Homoran [sagte]: zusätzliche 2GB für einen Prozess schon sehr viel.

Backitup liest und schreibt sehr viel. Da kann die Warteschlange im OS schon groß werden, wenn die I/O-Operationen ausbremsen.
Anmerkung: Ich bin kein Freund von automatischen Backups.

[Homoran]

@paul53 ich sitze zwar nicht morgens gegen 0300 vor dieser Tabelle

Aber nach der Theorie hätte dann heute morgen gegen 07:30/08:00 der mem Verbrauch von backitup deutlich höher sein müssen.

Oder geht die Speicherreservierung an iobroker vorbei?

Jetzt logge ich auch noch memHeapUsed von backitup.
Dabei reduziere ich gerade die Daten

[paul53]

@Homoran [sagte]: Oder geht die Speicherreservierung an iobroker vorbei?

Ja. Das OS hat einen eigenen Puffer. Was man mit "top" unter "buff/cache" sieht, hat nichts mit dem Speicher von ioBroker zu tun.

[Homoran]

@paul53 sagte:

Was man mit "top" unter "buff/cache

Ok, dann muss ich das mal beobachten.
Aber das wird ja nicht näher einem Prozess zugeordnet.

Die Tabelle zeigt halt alle Werte, die in top unter io.xxx gelistet sind.

Danke

[Homoran]

@paul53
Jetzt brauche ich nochmal etwas von deinem schier unendlichen Wissen 😉

Ich wollte analog zu

puh@BrokerRaspi:~ $ top | grep buff
MiB Mem :   8062.4 total,   1998.1 free,   4873.2 used,   1281.1 buff/cache
MiB Mem :   8062.4 total,   2044.9 free,   4826.4 used,   1281.1 buff/cache
MiB Mem :   8062.4 total,   2045.0 free,   4826.4 used,   1281.1 buff/cache
MiB Mem :   8062.4 total,   2049.0 free,   4822.1 used,   1281.3 buff/cache
MiB Mem :   8062.4 total,   2056.6 free,   4814.5 used,   1281.3 buff/cache
MiB Mem :   8062.4 total,   2053.1 free,   4818.0 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2057.6 free,   4813.5 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2047.4 free,   4823.7 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2053.5 free,   4817.5 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2052.9 free,   4818.1 used,   1281.5 buff/cache
MiB Mem :   8062.4 total,   2058.3 free,   4812.8 used,   1281.5 buff/cache
MiB Mem :   8062.4 total,   2061.0 free,   4810.0 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2056.4 free,   4814.4 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2061.1 free,   4809.8 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2064.6 free,   4806.2 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2058.2 free,   4812.6 used,   1281.7 buff/cache

eine blockly Abfrage starten.
Leider kommt kein result

Nur ein ERROR, mit dem ich nichts anfangen kann

Kannst du mir da helfen?

[paul53]

@Homoran [sagte]:
Leider kommt kein result

"top" ist kein Kommando, das sich nach Ausgabe auf stdout beendet, sondern es läuft in einem Fenster, das explizit geschlossen werden muss.
Verwende "free -m" (für kontinuierliche Ausgabe in einem Intervall ).

[Homoran]

@paul53 sagte:

Verwende "free -m" (für kontinuierliche Ausgabe in einem Intervall ).

Danke, bin ich gerade dabei.
Erstelle Liste aus result mit Trennzeichen ???
Hab es mit 5 Leerzeichen versucht und 9.lement genommen

[OliverIO]

@Homoran sagte:

@OliverIO sagte:

Wenn dann musst du auf available mem schauen.

Jetzt kann ich es dir zeigen!

Gegen 03:00+
Available bleibt hoch, steigt sogar an, aber free geht gegen 0.

Wenn da noch etwas dazukommt schlägt der oom-reaper zu.

Noch läuft das System durch, aber ich denke wir regeln gerade nur die Symptome, die Ursache liegt irgendwo anders.

Ich habe der ki mal das diagram gefüttert und hoffe die Farben richtig interpretiert zu haben
In der Antwort sind bashscripte, die direkt an der Basis aufzeichnet und nicht noch durch die ganze zeitverzögerung und zwischenverarbeitung des iobrokers verfälscht werden.

Prompt
Kannst du dir mal das diagram anschauen
Free Memory ist grün
Available mem ist orange
Rot ist was ein bestimmte Applikation (iobroker)
Benötigt.

Der starke Abfall an freiem Speicher ist nicht erklärbar. Wie könnte man rausfinden was auf einem linuxsystem das auslöst

Antwort

Ja. Das Diagramm ist sogar ziemlich interessant, weil „free“ (grün) massiv einbricht, während „available“ (orange) weitgehend stabil bleibt. Das ist unter Linux ein sehr wichtiger Unterschied.

Um ca. 03:10 Uhr passiert beispielsweise ungefähr:

• free: ~2,5 GB → fast 0
• available: bleibt bei ~3,1–3,3 GB
• ioBroker (rot): bleibt ebenfalls ungefähr gleich

Das spricht nicht unmittelbar für einen Prozess, der plötzlich 2,5 GB RAM belegt. Viel wahrscheinlicher verwendet der Linux-Kernel den vorher freien RAM für Page Cache / Buffers / Slab Cache. Dieser Speicher zählt dann nicht mehr als MemFree, kann aber bei Bedarf wieder freigegeben werden und steckt deshalb weiterhin in MemAvailable.

Als Erstes würde ich /proc/meminfo aufzeichnen

Auf dem betroffenen Rechner:

cat /proc/meminfo

Interessant sind insbesondere:

MemTotal
MemFree
MemAvailable
Buffers
Cached
SReclaimable
SUnreclaim
Slab
Shmem
AnonPages
Mapped
Dirty
Writeback
PageTables
KernelStack

Noch besser: alle 30 oder 60 Sekunden protokollieren, damit wir genau sehen, wohin die ~2,5 GB verschwinden:

while true; do
    echo "===== $(date '+%F %T') ====="
    grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|Slab|SReclaimable|SUnreclaim|Shmem|AnonPages|Mapped|Dirty|Writeback|PageTables|KernelStack' /proc/meminfo
    sleep 60
done >> /var/log/memtrace.log

Wenn der Effekt wieder auftritt, können wir beispielsweise feststellen:

MemFree       -2400 MB
Cached        +2350 MB

Dann ist der Fall praktisch geklärt: Filesystem/Page Cache.

Oder:

MemFree       -2400 MB
Slab          +2300 MB

Dann müssen wir uns Kernel-Caches genauer ansehen.

Oder:

MemFree       -2400 MB
AnonPages     +2300 MB

Dann suchen wir nach einem Prozess bzw. dessen Speicherallokationen.

Gleichzeitig die Prozesse überwachen

Ich würde zusätzlich regelmäßig die größten RAM-Verbraucher sichern:

ps -eo pid,ppid,user,rss,vsz,comm,args --sort=-rss | head -30

Automatisch:

while true; do
    echo "===== $(date '+%F %T') ====="
    ps -eo pid,ppid,user,rss,vsz,comm,args --sort=-rss | head -30
    sleep 60
done >> /var/log/procmemtrace.log

Damit sieht man hinterher z. B.:

03:09  postgres    200 MB
03:10  postgres    220 MB

→ nicht der Verursacher.

Oder:

03:09  irgendwas    50 MB
03:10  irgendwas  2400 MB

→ Volltreffer.

Falls es Slab/Kernel-Speicher ist

Dann ist

sudo slabtop

sehr hilfreich.

Alternativ:

cat /proc/slabinfo

Ein stark wachsender dentry/inode-Cache kann beispielsweise durch sehr viele Dateioperationen entstehen.

---

Ein Detail in deinem Diagramm finde ich besonders auffällig: Um ~03:10 fällt free praktisch auf null, aber available überhaupt nicht entsprechend mit. Genau dieses Verhalten ist eigentlich typisch für Speicher, den Linux problemlos wiederverwenden kann.

Deshalb würde ich zunächst keinen Memory Leak bei ioBroker vermuten. Die rote Linie unterstützt das ebenfalls: Sie macht um 03:10 keinen entsprechenden Sprung.

Wenn du möchtest, können wir das noch zielgerichteter machen: Ich kann dir ein kleines Bash-Script bauen, das alle 10 Sekunden Free/Available/Cache/Slab und die Top-20-Prozesse protokolliert und bei einem plötzlichen Free-RAM-Abfall automatisch einen detaillierten Snapshot erzeugt. Damit sollten wir den Verursacher beim nächsten Ereignis ziemlich zuverlässig erwischen.

[OliverIO]

Hier das am Ende erwähnte Script

Klar. Ich würde es so bauen, dass es dauerhaft leichtgewichtig mitloggt und bei einem plötzlichen Einbruch von MemFree automatisch einen ausführlicheren Snapshot erzeugt.

Speichere das z. B. als /usr/local/sbin/memwatch.sh:

#!/usr/bin/env bash

LOGDIR="/var/log/memwatch"
INTERVAL=10
DROP_THRESHOLD_KB=$((512 * 1024))   # Trigger bei >512 MB Verlust seit letzter Messung
KEEP_DAYS=14

mkdir -p "$LOGDIR"

MAINLOG="$LOGDIR/memory.log"

cleanup_old_logs() {
    find "$LOGDIR" -type f -mtime +"$KEEP_DAYS" -delete 2>/dev/null
}

get_memfree() {
    awk '/^MemFree:/ {print $2}' /proc/meminfo
}

log_basic_snapshot() {
    {
        echo "===== $(date '+%F %T') ====="

        grep -E \
        '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapCached|Active|Inactive|AnonPages|Mapped|Shmem|Slab|SReclaimable|SUnreclaim|KernelStack|PageTables|Dirty|Writeback|SwapTotal|SwapFree):' \
        /proc/meminfo

        echo "--- load ---"
        cat /proc/loadavg

        echo
    } >> "$MAINLOG"
}

log_detailed_snapshot() {
    TS="$(date '+%Y%m%d_%H%M%S')"
    SNAP="$LOGDIR/snapshot_$TS.log"

    {
        echo "############################################################"
        echo "MEMORY EVENT SNAPSHOT"
        echo "Time: $(date '+%F %T')"
        echo "############################################################"
        echo

        echo "===== /proc/meminfo ====="
        cat /proc/meminfo
        echo

        echo "===== free -h ====="
        free -h
        echo

        echo "===== vmstat ====="
        vmstat 1 5
        echo

        echo "===== Top processes by RSS ====="
        ps -eo pid,ppid,user,%mem,rss,vsz,stat,comm,args \
            --sort=-rss | head -40
        echo

        echo "===== Top processes by VSZ ====="
        ps -eo pid,ppid,user,%mem,rss,vsz,stat,comm,args \
            --sort=-vsz | head -40
        echo

        echo "===== Slab summary ====="
        if command -v slabtop >/dev/null 2>&1; then
            slabtop -o -s c | head -40
        else
            head -100 /proc/slabinfo
        fi
        echo

        echo "===== Filesystem ====="
        df -h
        echo

        echo "===== inode usage ====="
        df -i
        echo

        echo "===== mounts ====="
        mount
        echo

        echo "===== system load ====="
        uptime
        echo

        echo "===== pressure stall information ====="
        for f in /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory; do
            if [ -f "$f" ]; then
                echo "--- $f ---"
                cat "$f"
            fi
        done
        echo

        echo "===== dmesg memory related ====="
        dmesg --ctime 2>/dev/null | \
            grep -Ei 'memory|oom|out of memory|killed process|page allocation|slab' | \
            tail -100
        echo

        if command -v journalctl >/dev/null 2>&1; then
            echo "===== journal last 10 minutes ====="
            journalctl --since "-10 min" --no-pager 2>/dev/null | tail -300
        fi

    } > "$SNAP"

    echo "$(date '+%F %T') EVENT snapshot written: $SNAP" >> "$MAINLOG"
}

cleanup_old_logs

PREV_FREE="$(get_memfree)"

while true; do

    CURRENT_FREE="$(get_memfree)"

    log_basic_snapshot

    if [[ "$PREV_FREE" =~ ^[0-9]+$ ]] && [[ "$CURRENT_FREE" =~ ^[0-9]+$ ]]; then

        DROP=$((PREV_FREE - CURRENT_FREE))

        if (( DROP >= DROP_THRESHOLD_KB )); then
            {
                echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
                echo "$(date '+%F %T') MEMORY DROP DETECTED"
                echo "Previous MemFree: $((PREV_FREE / 1024)) MB"
                echo "Current  MemFree: $((CURRENT_FREE / 1024)) MB"
                echo "Drop:             $((DROP / 1024)) MB"
                echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
            } >> "$MAINLOG"

            log_detailed_snapshot
        fi
    fi

    PREV_FREE="$CURRENT_FREE"

    sleep "$INTERVAL"
done

Dann ausführbar machen:

sudo chmod +x /usr/local/sbin/memwatch.sh

Zum Testen zunächst einfach im Terminal starten:

sudo /usr/local/sbin/memwatch.sh

Die laufenden Messwerte landen dann hier:

/var/log/memwatch/memory.log

Bei einem starken Einbruch entsteht zusätzlich z. B.:

/var/log/memwatch/snapshot_20260830_031023.log

Darin stehen dann Prozesse, meminfo, Slab-Cache, vmstat, Kernelmeldungen usw.

Als systemd-Service laufen lassen

Ich würde es anschließend als Dienst einrichten. Datei:

sudo nano /etc/systemd/system/memwatch.service

mit:

[Unit]
Description=Memory Drop Monitor
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/memwatch.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Dann:

sudo systemctl daemon-reload
sudo systemctl enable --now memwatch.service

Status prüfen:

systemctl status memwatch.service

und live ins Log schauen:

tail -f /var/log/memwatch/memory.log

Ich würde bei deinem Diagramm besonders auf Cached, SReclaimable, SUnreclaim, AnonPages und Shmem achten. Wenn der grüne Wert beim nächsten Mal wieder um mehrere GB fällt, können wir anhand des Snapshots ziemlich genau unterscheiden, ob es Filesystem-Cache, Kernel-Slab, tmpfs/shared memory oder tatsächlich ein Prozess war.

Für deinen Fall würde ich den Trigger eventuell sogar auf 256 MB innerhalb von 10 Sekunden setzen:

DROP_THRESHOLD_KB=$((256 * 1024))

Dann erwischen wir auch kleinere Vorstufen des großen Einbruchs. Wenn du mir danach memory.log plus einen der snapshot_*.log hier hochlädst, kann ich dir daraus den wahrscheinlichsten Verursacher herauslesen.

[OliverIO]

@Homoran

Also ich würde primär mal das letzte Monitoring Script laufen lassen.

Wenn dann wieder ein Absturz war, kannst Du es selber mal bei der ki probieren. Die kostenlosen bspw bei OpenAI haben idR ein schwächeres Modell dahinter das evtl. in der Analyse nicht ganz so gut ist.
Du kannst es aber auch gerne hier posten dann füttere ich das meinem bezahlaccount mit OpenAI sol

[Homoran]

@OliverIO DANKE!

bis ich das alles verstanden und nachgebaut habe müssten wir mit dem bisher von mir Datenmessie gesammelten Daten zurechtkommen.
Zusätzlich zu dem bisherigen (KI hat das ja genauso interpretiert wie ich) habebich jetzt den buffer noch unter Beobachtung

Allerdings erst seit paar Minuten

Kurz danach sank available kurz und massiv, memfree stieg um 1GB und buffer fiel um 800MB

memfree und available sind auf minimun aggregiert, buffer auf minmax

[Homoran]

@OliverIO ich hab ja schon Probleme, wie ich das

@OliverIO sagte:

Speichere das z. B. als /usr/local/sbin/memwatch.sh:

Speichern soll!?

sudo nano /usr/local/sbin/memwatch.sh aufrufen -> leere Datei -> reinkopieren -> sichern???

---

Davon ab
03:10 wird das packen der history Daten beim Backup sein.

Diese ist das schlechteste Beispiel, weil

@OliverIO sagte:

Genau dieses Verhalten ist eigentlich typisch für Speicher, den Linux problemlos wiederverwenden kann.

Und iob wurde noch nie beim backup gekillt.

---

@OliverIO sagte:

Available mem ist orange
Rot ist was ein bestimmte Applikation (iobroker)
Benötigt.

Nein!
Beides ist wahrscheinlich available, einmal von mir abgerufen (orange) und einmal von system.host.xxx.freeMem (rot)

---