Monatsrückblick Juli / August 2026 ist online!

[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)

---

[OliverIO]

@Homoran

Hier ist ja eine Schritt für Schritt Anleitung enthalten
https://forum.iobroker.net/topic/85236/load-average-am-anschlag-neustart/107?_=1788105751660

Du sollst das nicht nachbauen.
Sondern so verwenden

Zur Funktionsweise, soweit es oben nicht schon steht.
Das Skript ruft alle 10 Sekunden das freemen aus /proc/meminfo und /proc/loadavg
Das ist einer der internen Monitoring "Dateien" aus denen sich bspw top die Informationen holt und diese hübsch aufbereitet.

Wenn das Skript dann einen freemen drop bemerkt erstellt er einen detaillierten snapshot. Also texting mit Informationen aus verschiedenen Tools und Monitoring Dateien

Bspw
Ps der process Explorer von Linux
Free = freier Speicher und swap
Vmstat = nochmal diverse Kennzahlen aus den verschiedenen kernelbereichen von Linux
Slabtop = kannte ich selbst noch nicht. Zeigt aber wie top Kennzahlen zu dem was Linux selbst so an Memory braucht auch zu den verschiedenen kernelbereichen.
Alternativ liest es aus /proc/slabinfo, was aber nur den aktuellen Stand zeigt.

Ohje wenn du datenmessie ist habe ich dich jetzt getriggert und gefüttert.

Wie erwähnt, das obige Script ist nur ein temporäres Analyse Script um überhaupt rauszufinden was das verursacht.
In einem Nebensatz, war die unbestätigte Vermutung, das es der ionde/filecache ist. Was ggfs auch mit den Tätigkeiten des history Adapters zu tun haben könnte.
Wenn man mal so einen snapshot erhält und analysiert hat, benötigt man es nicht mehr.

Hast du da datenpunkte, bei denen die history Dateien an einem Tag sehr groß werden, weil du zu detailliert aufzeichnest?
Die muss der history Adapter alle komplett öffnen, damit er die Aktualisierungen hinten anhängen kann.

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

Ja, Nano ist der Editor von Linux
https://wiki.ubuntuusers.de/Nano/

Text kopieren
Dann die Zeile mit Nano aufrufen
Dann im leerenbereich rechte Maustaste zum einfügen
Dann Strg+o zum speichern
Dann Strg+x zum schließen

Den systemd Dienst kannst du weglassen, wenn du die console mit der du das Skript startest geöffnet lassen kannst und der Rechner auch nicht in den sleep Modus wechselt. Sonst wird die Konsole beendet und damit auch das Skript.
Man könnte das Skript auch direkt als deamon starten, aber wollen es nicht zu kompliziert und verwirrend machen

[Homoran]

Danke nochmals für deine Mühen.
Ich hab das soweit schon (fast) alles verstanden.
Slab kannte ich aber auch noch nicht, geschweige denn wo man an diese Info kommt.

Nano kenne ich schon ganz gut, im Gegensatz zu vi.
Nur einfach den code reinkopieten in den Pfad könnte ich nicht.
Mein Vorgehen wäre das vorgeschlagene.
Danke für die Bestätigung!

Wenn das skript wirklich leichtgewichtig idt sollte es wie von der ki empfohlen auch dauernd laufen ohne dass ich die Konsole offen halten muss

Was den Datenmessie angeht lief iobroker bisher ohne Probleme mit 450 Datenpunkten von 5+ Jahren.
Müssen ca. 120GB gewesen sein, gepackt waren es zuletzt 4.7GB. Das packen dauerte etwa 50 Minuten

Mittlerweile habe ich 2 Jahre, etwa 30+GB gelöscht, und bei vielen DP die Aufbewavon unendlich auf 2 Jahre gekürzt. Leider gehen 3 yjahre nicht

[OliverIO]

@Homoran

Dann weiter viel Glück beim beobachten

[Homoran]

@OliverIO hab noch was editiert

[Homoran]

@OliverIO
Nachdem wir so viel an den Symptomen gebastelt haben und iob inzwischen schon 1.7 Tage lief, hab ich wirklich gedacht: das war's!

Pustekuchen!
Heute Nacht ist iob 2-3x neu gestartet

Das anschließende backitup hat er wie i mer problemlos überstanden.

Ich hab jetzt das KI logging (hoffentlich richtig- aktiviert

===== 2026-08-31 08:50:45 =====
MemTotal:        8255872 kB
MemFree:         2875856 kB
MemAvailable:    3263424 kB
Buffers:          152512 kB
Cached:           317808 kB
SwapCached:          672 kB
Active:          2748256 kB
Inactive:        1377264 kB
SwapTotal:       2097136 kB
SwapFree:        1000208 kB
Dirty:               240 kB
Writeback:             0 kB
AnonPages:       3654736 kB
Mapped:            66976 kB
Shmem:              4080 kB
Slab:             321040 kB
SReclaimable:     225696 kB
SUnreclaim:        95344 kB
KernelStack:       10608 kB
PageTables:       345408 kB
--- load ---
0.34 0.38 0.48 1/660 95481

Weisst du ob das log unendlich geschrieben wird oder irgenwann wieder teilweise gelöscht ?

Was mir auffällt ist dass der swap mittlerweile schon zu 1GB verbraucht ist.
Das geht natürlich auch in die I/O Belastung

Aus dem journal (nur die errors)

Aug 30 22:14:07 BrokerRaspi systemd-udevd[380]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, i>Aug 30 22:14:07 BrokerRaspi systemd-udevd[380]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 The line has no effect any more, dropping.
Aug 30 22:14:07 BrokerRaspi systemd-udevd[380]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, i>Aug 30 22:14:07 BrokerRaspi systemd-udevd[380]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 The line has no effect any more, dropping.
.
.
.
Aug 30 22:14:08 BrokerRaspi systemd[1]: Reached target remote-fs.target - Remote File Systems.
Aug 30 22:14:08 BrokerRaspi blkmapd[765]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Aug 30 22:14:08 BrokerRaspi systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon.
.
.
.

Aug 30 22:14:10 BrokerRaspi bluetoothd[792]: Bluetooth daemon 5.82
Aug 30 22:14:10 BrokerRaspi kernel: raspberrypi-firmware soc@107c000000:firmware: Request 0x00030097 returned status 0x80000001
Aug 30 22:14:10 BrokerRaspi systemd[1]: sshswitch.service: Deactivated successfully.
.
.
.
Aug 30 23:58:04 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=>Aug 30 23:58:04 BrokerRaspi kernel: Out of memory: Killed process 1190 (iobroker.js-con) total-vm:12241856kB, anon-rss:326736kB, file-rss:256kB>Aug 30 23:58:07 BrokerRaspi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILL
.
.
.
Aug 31 00:24:01 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=>Aug 31 00:24:01 BrokerRaspi kernel: Out of memory: Killed process 29115 (iobroker.js-con) total-vm:12270864kB, anon-rss:234672kB, file-rss:96kB>Aug 31 00:24:02 BrokerRaspi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILL
.
.
.
Aug 31 03:55:55 BrokerRaspi kernel: cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Aug 31 03:55:55 BrokerRaspi kernel: cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Aug 31 03:55:55 BrokerRaspi kernel: usb 3-2.1.3: USB disconnect, device number 8
Aug 31 03:55:55 BrokerRaspi kernel: cp210x ttyUSB0: failed set request 0x7 status: -19
Aug 31 03:55:55 BrokerRaspi kernel: cp210x ttyUSB0: failed set request 0x12 status: -19
Aug 31 03:55:55 BrokerRaspi kernel: cp210x ttyUSB0: failed set request 0x0 status: -19
.
.
.

[OliverIO]

@Homoran

Das Script löscht Dateien alter als 14 tage
Kann man mit dem Parameter am Anfang des Skript einstellen. Keep Days

Wir warten auf eine snapshot Datei
Auf wieviel hast du drop threshoud eingestellt

Das Script wartet darauf das das freemen um 512mb fällt.
Wie die KI erwähnte, kannst du es auch empfindlicher einstellen mit 256

[Homoran]

@OliverIO sagte:

Auf wieviel hast du drop threshoud eingestellt

ich hab nur kopiert!

Muss7ch mir ansehen

Edit

@OliverIO sagte:

DROP_THRESHOLD_KB=$((512 * 1024)) # Trigger bei >512 MB Verlust seit letzter Messung

Hier die 512 gegen 256 ändern?

[paul53]

@Homoran [sagte]:
backitup hat er wie i mer problemlos überstanden.

Man sieht, das dabei "buffer" um 1,8 GB steigt.
Der Grund für die Abstürze ist offenbar ein anderer.