Load average am Anschlag -> Neustart

Homoran

Ganz ganz lieben Dank!

Vieles passt zu dem was ich vermutet habe, aber mangels Wissens nicht so tief durchschaue.

Bin nur kurz zu Hause und muss sofort wieder los!

Wenn ich es richtig verstanden habe:

script komplett ersetzen
den Service neu starten
logs löschen

...und warten?

Nach den execs sehe ich nachher.
Was ich definitiv weiss ist das exec für free -m alle 15 sekunden

OliverIO

@Homoran

Ja genau so vorgehen.
Achtung, im Vergleich zum letzten Skript, ist das einfach ein Copy und Paste Befehl.
Einfach kopieren und auf deiner Konsole einfügen und ausführen sofern du die Pfade nicht geändert hast

OliverIO

@Homoran

Eilt ja nicht, ist ja dein Rechner :)

Homoran

puh@BrokerRaspi:~ $ sudo systemctl restart memwatch.service
puh@BrokerRaspi:~ $ systemctl status memwatch.service
● memwatch.service - Memory Drop Monitor
     Loaded: loaded (/etc/systemd/system/memwatch.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Mon 2026-08-31 14:01:07 CEST; 2s ago
 Invocation: 661e703cd9e5457f9f6bbe0df09f5248
    Process: 222183 ExecStart=/usr/local/sbin/memwatch.sh (code=exited, status=203/EXEC)
   Main PID: 222183 (code=exited, status=203/EXEC)
        CPU: 6ms
puh@BrokerRaspi:~ $ tail -f /var/log/memwatch/memory.log
tail: cannot open '/var/log/memwatch/memory.log' for reading: No such file or directory
tail: no files remaining

Homoran

@OliverIO sagte:

und ausführen

Das war's

Danke, läuft!

Bin gespannt

Homoran

@OliverIO sagte:

hast du in einem deinen javascripts etwas was das uU viel den exec befehl auslösen könnte?

In allen Blockly mit exec: trigger alle 15 Sekunden
Im js alle 2 Minuten

EDIT: Plattendaten alle 10 Minuten

OliverIO

@Homoran

du musst schauen ob um so ein exec eine schleife liegt die entsprechend oft so ein exec ausführt
oder eine funktion mit einem trigger,die ein exec enthält, was entsprechend oft aufgerufen wird.
auch setInterval oder setTimeout sind gefährlich
auch runScript/startScript oder
schedule in einer schleife oder innerhalb eines triggers

ggfs mal vor jedes Exec oder andere Befehle eine log ausgabe setzen. Dann sieht man es im log wie oft so etwas ausgeführt wird.

ist nur eine idee. die analyse wird uns maximal auf den prozess bringen. wenn das ergebnis javascript adapter ist, muss man da drin dann einzeln suchen.
aber mal schauen, evtl ist es auch ein anderer prozess

Homoran

@OliverIO sagte:

so ein exec eine schleife liegt die entsprechend oft so ein exec

Nein, niemals!
Einfaches aufrufen, auswerten, schreiben

@OliverIO sagte:

die analyse wird uns maximal auf den prozess bringen

Falls das js ist muss ich weitersuchen.

Das neue Skript läuft leider erst nach dem großen drop und hat bisher drei drops gefunden
snapshot_20260831_140543.log snapshot_20260831_142136.log snapshot_20260831_141701.log

Wobei in meinen Augen der um 14:21 i terssant sein könnte weil da die Load höher ging (erwa 3)
Hier das log von 14:24

1424memory.log

Michael Schmitt

Hiho,
ich kenn mich mal garnicht mit dem aus was ihr hier alles schreibt und macht, aber denoch verfolge ich es (wer weis für was es gut ist). Ich hab zum Spaß mal das Script dem kostenlosen Claude hingeworfen und der findet es super und auch die Auswertung und Analyse von @oliverio ist korekt.
Er hat hur einen Verbesserungsvorschlag =

Ein zusätzlicher Punkt, den man noch ergänzen könnte, falls der andere User es nicht schon vorhat: Da das Intervall des Hauptloops bei 5 Sekunden liegt und der Peak selbst nur wenige Sekunden dauert, könnte es sinnvoll sein, während eines erkannten Triggers kurzzeitig das Polling-Intervall zu verkürzen (z.B. auf 0,5–1 Sekunde für die nächsten 10 Sekunden), um die Chance zu erhöhen, den Prozess-Storm überhaupt im richtigen Moment zu erwischen – aktuell hängt der Erfolg stark davon ab, dass der 5-Sekunden-Tick zufällig mitten in den Peak fällt.

dachte nur dass euch das vielleicht hilft ;)

Homoran

@Michael-Schmitt klingt sinnvoll.
Aber ich weiss ja auch nicht was hier abgeht

Wollte gerade los ne nvme und eine icybox zu holen um den anderen pi mit wasauchimmer als OS zu füttern und sehen ob es auch dann die selben Probleme gibt.
Hab es auf morgen verschoben

OliverIO

@Michael-Schmitt
sehr schön wenn sich die KIs gegenseitig loben :)

OliverIO

@Homoran

hier die neue analyse. leider mit noch nicht ganz so eindeutigen hinweisen.
auch leben diese tasks zu kurz als das der 5 sekunden rythmus ausgereicht hätte. das Ereignis um 14:21 war auch nicht stark genug.

Analyse der memwatch-Logs vom 31.08.2026

Kurzfazit

Die Dateien belegen einen kurzlebigen Task-/Thread-Sturm am 31.08.2026 um
14:21:36. Innerhalb eines Messintervalls von fünf Sekunden stieg die Taskzahl
von 679 auf 891, also um 212. Gleichzeitig gingen rund 400 MB verfügbarer
Speicher verloren.

Der Sturm war beim Schreiben des detaillierten Snapshots bereits teilweise
vorbei: Dort wurden nur noch 736 Tasks gezählt. Deshalb ist der eigentliche
Verursacher in der normalen Prozessliste nicht mehr vollständig enthalten.

Der auffälligste zeitliche Zusammenhang ist der ioBroker-Adapter
system.adapter.dwd.0: Sein Prozess io.dwd.0 (PID 229073, Parent PID 39859)
wurde um 14:21:33 gestartet, nur drei Sekunden vor dem Peak. Im Snapshot
belegte er bereits 180.544 kB RSS. Damit ist dwd.0 der derzeit stärkste
Verdächtige, aber anhand dieser Dateien noch nicht zweifelsfrei als Erzeuger
aller 212 zusätzlichen Tasks bewiesen.

Ausgewertete Dateien

1788179405632-1424memory.log
1788179326889-snapshot_20260831_140543.log
1788179326893-snapshot_20260831_141701.log
1788179326891-snapshot_20260831_142136.log

Erkannte Ereignisse

Zeitpunkt	MemFree-Abfall	MemAvailable-Abfall	Taskänderung	Tasks am Trigger	Besonderheit
14:05:43	392 MB	301 MB	+3	652	Speicherimpuls ohne Task-Sturm
14:17:01	285 MB	285 MB	+18	678	Speicherimpuls, kleiner Taskanstieg
14:21:36	389 MB	400 MB	+212	891	klarer Task-/Thread-Sturm

Alle drei Ereignisse waren kurzlebig. Bereits bei den jeweils nächsten
Messungen hatte sich ein wesentlicher Teil des Speicherverbrauchs wieder
zurückgebildet. Das spricht eher für kurz gestartete Prozesse/Threads oder eine
kurze, speicherintensive Adapteraktivität als für ein stetiges Speicherleck.

Detailanalyse des Ereignisses um 14:21:36

Zwischen den beiden Messpunkten änderten sich die wichtigsten Werte ungefähr
wie folgt:

Tasks: 679 -> 891 (+212)
MemAvailable: 3.546 MB -> 3.146 MB (-400 MB)
MemFree: 2.908 MB -> 2.519 MB (-389 MB)
AnonPages: etwa 3.428 MB -> 3.807 MB (ca. +379 MB)
PageTables: etwa 340 MB -> 376 MB (ca. +36 MB)
KernelStack: etwa 10,6 MB -> 13,9 MB (ca. +3,2 MB)

Die Kombination aus deutlich steigenden AnonPages, PageTables,
KernelStack und Tasks passt technisch zu sehr vielen kurzfristig angelegten
Ausführungskontexten. Sie passt weniger zu einem reinen Dateicache- oder
Slab-Problem.

Der Snapshot zeigt unmittelbar danach:

242 Prozesse und 736 Tasks; gegenüber den 891 Tasks am Trigger waren also
bereits 155 Tasks wieder verschwunden.
io.dwd.0, PID 229073, PPID 39859, gestartet um 14:21:33.
io.dwd.0 hatte 12 noch sichtbare Threads und 180.544 kB RSS.
Der ioBroker-Controller PID 39859 war der Parent der Adapterprozesse.
Kein noch sichtbarer Prozess hatte im Snapshot eine ungewöhnlich hohe
Threadzahl; die ioBroker-/Node-Prozesse lagen überwiegend bei 11 oder 12.

Das bedeutet: Die zusätzlichen Tasks waren entweder sehr kurzlebig oder der
Peak wurde in einer Phase erfasst, die vor dem ersten ps-Snapshot schon
endete. Die verbleibenden 12 Threads von dwd.0 erklären den Peak allein
nicht. Der Startzeitpunkt und sein hoher anfänglicher RSS machen den Adapter
aber zum besten konkreten Ansatzpunkt.

Die anderen beiden Ereignisse

14:05:43

Der Speicherverlust von 301 MB bei MemAvailable trat bei nur drei zusätzlichen
Tasks auf. Die Prozessliste zeigt keinen Thread-Sturm und keinen einzelnen neu
gestarteten Großverbraucher. Der Effekt bildete sich schnell zurück.

14:17:01

Der Speicherverlust von 285 MB trat zusammen mit 18 zusätzlichen Tasks auf.
Auch hier zeigt der Snapshot keinen Prozess mit auffälliger Threadzahl. Um
14:17:01 lief zusätzlich /etc/cron.hourly; das ist zeitlich korreliert, aber
die vorliegenden Daten belegen keine ursächliche Verbindung.

Weitere relevante Beobachtungen

Swap war bereits mit etwa 1,1 GiB von 2,0 GiB belegt. Während der fünf
vmstat-Sekunden fand beim Ereignis aber kein aktuelles Ein- oder Ausswappen
statt (si/so jeweils 0 nach der Summenzeile).
Die CPU-Last stieg kurz an und fiel innerhalb weniger Sekunden wieder ab.
Die Slab-Auswertung war unauffällig; insbesondere erklärt der Slab-Verbrauch
nicht den kurzfristigen Verlust von etwa 400 MB.
Es gab während dieser drei Snapshots keinen neuen OOM-Kill. Die in dmesg
enthaltenen OOM-Einträge stammen von 23:58:02 und 00:24:01 und damit aus
früheren Ereignissen. Damals wurden ioBroker-Controller-Prozesse beendet.
Die SSH-Anmeldung des Benutzers puh um 14:13 erzeugte nur wenige Prozesse
und erklärt den Peak um 14:21 nicht.

Fehler und Lücken im aktuellen Messskript

1. Parent-Auswertung bricht ab

Im Journal steht bei jedem Snapshot:

/usr/local/sbin/memwatch.sh: line 264: PPID: readonly variable

PPID ist in Bash eine reservierte, schreibgeschützte Variable. Dadurch bleibt
der Abschnitt TOP PARENTS WITH PROCESS INFORMATION leer. In der Schleife muss
die Variable beispielsweise PARENT_PID heißen:

while read -r COUNT PARENT_PID; do
    if [[ "$PARENT_PID" =~ ^[0-9]+$ ]] && [ "$PARENT_PID" -gt 0 ]; then
        INFO="$(ps -p "$PARENT_PID" -o pid=,ppid=,user=,nlwp=,rss=,vsz=,stat=,comm=,args= 2>/dev/null)"
        printf "%6s children | %s\n" "$COUNT" "$INFO"
    fi
done

2. `FULL THREAD LIST` ist leer

In allen drei Snapshots folgt direkt nach der Überschrift FULL THREAD LIST
bereits PROCESS TREE. Das verwendete ps -eLf -o ... liefert auf diesem
System offenbar keine Daten (der Fehler wird durch 2>/dev/null verborgen).
Vor dem nächsten Lauf sollte der Befehl direkt auf dem Raspberry Pi getestet
werden. Eine robustere Variante ist beispielsweise:

ps -eL -o pid,ppid,lwp,nlwp,user,psr,stat,rss,vsz,comm,args

3. Snapshot-Erfassung dauert etwa fünf Sekunden

Zwischen Triggerzeit und snapshot written liegen jeweils vier bis fünf
Sekunden. Schon vor dem ersten detaillierten Taskwert war beim stärksten
Ereignis ein großer Teil des Sturms vorbei. Für solche Peaks sollte beim Trigger
zuerst eine sehr schnelle Rohkopie von /proc beziehungsweise mindestens eine
sofortige Threadliste in eine separate Datei geschrieben werden. Erst danach
sollten Sortierungen und mehrfache ps-Aufrufe folgen.

4. Taskzahl im Trigger und Snapshot unterscheiden sich

Das ist kein Rechenfehler: memory.log misst 891 Tasks am Trigger, während der
nachfolgende Snapshot 736 anzeigt. Diese Differenz ist gerade ein wichtiger
Hinweis auf die kurze Lebensdauer der zusätzlichen Tasks.

Bewertung der wahrscheinlichsten Ursache

Sehr wahrscheinlich: ein kurzlebiger Prozess-/Thread-Sturm verursacht
den starken Peak um 14:21:36.
Wahrscheinlichster konkreter Auslöser: Start oder Startaktivität von
system.adapter.dwd.0, da io.dwd.0 drei Sekunden vor dem Peak neu gestartet
wurde und unmittelbar 180 MB RSS belegte.
Noch nicht bewiesen: Ob dwd.0 selbst alle zusätzlichen Tasks erzeugte,
ob ein von ihm ausgelöster Node-/Systemvorgang beteiligt war oder ob ein
zeitgleicher, bereits verschwundener Prozess verantwortlich war.
Unwahrscheinlich als alleinige Ursache: Slab, Dateicache, SSH-Sitzung oder
ein dauerhaft wachsender einzelner ioBroker-Prozess.

Empfohlene nächste Schritte

Die Variable PPID im Skript in PARENT_PID umbenennen.
Den Befehl für FULL THREAD LIST korrigieren und seine Fehler vorübergehend
nicht nach /dev/null umleiten.
ioBroker-Logs für system.adapter.dwd.0 im Zeitraum 14:21:25 bis 14:21:45
sichern und prüfen, warum der Adapter um 14:21:33 gestartet wurde.
In den ioBroker-Objekten/Logs die Restart-Zahl und den Exit-Grund von
dwd.0 prüfen.
Für den nächsten Peak eine minimale Soforterfassung vor allen aufwendigen
Befehlen ergänzen, etwa ps -eL ... und eine Liste aller numerischen
/proc/<PID>/task/<TID>-Einträge.
Optional dwd.0 kontrolliert deaktivieren und beobachten, ob die Peaks
ausbleiben. Das wäre ein aussagekräftiger A/B-Test, sollte aber nur erfolgen,
wenn der vorübergehende Ausfall der DWD-Daten akzeptabel ist.

Gesamtergebnis

Das verbesserte Monitoring hat die bisherige Vermutung grundsätzlich bestätigt:
Mindestens eines der Speicherereignisse ist mit einem massiven, sehr kurzen
Taskanstieg gekoppelt. Der Snapshot kam noch knapp zu spät, um sämtliche Tasks
ihrem Prozess zuzuordnen. dwd.0 ist aufgrund seines Startzeitpunkts der klare
Hauptverdächtige. Für einen belastbaren Beweis müssen die beiden fehlerhaften
Snapshot-Abschnitte repariert und die erste Threadliste noch früher geschrieben
werden.

OliverIO

@Homoran

daher hier ein neues verbessertes script.
einfach mit nano das bisherige script ersetzen.
das letzte skript hatte wohl probleme mit der ausführung eines bestimmten ps befehls

#!/usr/bin/env bash

# Monitors memory and task changes and writes a fast process/thread capture
# before producing a more expensive diagnostic snapshot.

set -u

LOGDIR="/var/log/memwatch"
INTERVAL=5
DROP_THRESHOLD_KB=$((256 * 1024))
AVAILABLE_DROP_THRESHOLD_KB=$((256 * 1024))
TASK_JUMP_THRESHOLD=200
TASK_ABSOLUTE_THRESHOLD=1200
AVAILABLE_LOW_KB=$((768 * 1024))
COOLDOWN_SECONDS=15
KEEP_DAYS=14

mkdir -p "$LOGDIR"
MAINLOG="$LOGDIR/memory.log"
LAST_SNAPSHOT_TIME=0

get_meminfo_value() {
    awk -v key="$1" '$1 == key ":" {print $2}' /proc/meminfo
}

get_memfree() { get_meminfo_value MemFree; }
get_memavailable() { get_meminfo_value MemAvailable; }
get_anonpages() { get_meminfo_value AnonPages; }
get_pagetables() { get_meminfo_value PageTables; }
get_kernelstack() { get_meminfo_value KernelStack; }

get_process_count() {
    ps -e --no-headers 2>/dev/null | wc -l
}

get_task_count() {
    awk '{split($4,a,"/"); print a[2]}' /proc/loadavg
}

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

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|Committed_AS):' /proc/meminfo
        echo "--- processes/tasks ---"
        echo "Processes: $(get_process_count)"
        echo "Tasks:     $(get_task_count)"
        echo "--- load ---"
        cat /proc/loadavg
        echo
    } >> "$MAINLOG"
}

log_detailed_snapshot() {
    local reason="$1"
    local ts snap fast_threads fast_processes

    ts="$(date '+%Y%m%d_%H%M%S')"
    snap="$LOGDIR/snapshot_$ts.log"
    fast_threads="$LOGDIR/.fast_threads_$ts.tmp"
    fast_processes="$LOGDIR/.fast_processes_$ts.tmp"

    # Capture volatile data first. Do not put other commands before these.
    # Errors are retained so a broken ps format cannot silently create an
    # empty section again.
    ps -eL -o pid,ppid,lwp,nlwp,user,psr,stat,rss,vsz,comm,args \
        > "$fast_threads" 2>&1 || true
    ps -eo pid,ppid,user,nlwp,%mem,rss,vsz,stat,lstart,comm,args \
        > "$fast_processes" 2>&1 || true

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

        echo "===== FAST THREAD CAPTURE (FIRST ACTION) ====="
        cat "$fast_threads"
        echo

        echo "===== FAST PROCESS CAPTURE (SECOND ACTION) ====="
        cat "$fast_processes"
        echo

        echo "===== IMMEDIATE SYSTEM STATE ====="
        echo "Processes: $(get_process_count)"
        echo "Tasks:     $(get_task_count)"
        cat /proc/loadavg
        echo

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

        echo "===== PROCESSES WITH MOST THREADS ====="
        ps -eo pid,ppid,user,nlwp,%mem,rss,vsz,stat,lstart,comm,args \
            --sort=-nlwp 2>&1 | head -100
        echo

        echo "===== TOP PROCESSES BY RSS ====="
        ps -eo pid,ppid,user,nlwp,%mem,rss,vsz,stat,lstart,comm,args \
            --sort=-rss 2>&1 | head -100
        echo

        echo "===== TOP PROCESSES BY VSZ ====="
        ps -eo pid,ppid,user,nlwp,%mem,rss,vsz,stat,lstart,comm,args \
            --sort=-vsz 2>&1 | head -100
        echo

        echo "===== PROCESS COUNT GROUPED BY PPID ====="
        ps -eo ppid= 2>/dev/null | sort -n | uniq -c | sort -nr | head -100
        echo

        echo "===== TOP PARENTS WITH PROCESS INFORMATION ====="
        ps -eo ppid= 2>/dev/null |
            sort -n |
            uniq -c |
            sort -nr |
            head -50 |
            while read -r count parent_pid; do
                if [[ "$parent_pid" =~ ^[0-9]+$ ]] && (( parent_pid > 0 )); then
                    parent_info="$(ps -p "$parent_pid" -o pid=,ppid=,user=,nlwp=,rss=,vsz=,stat=,comm=,args= 2>/dev/null)"
                    printf "%6s children | %s\n" "$count" "$parent_info"
                fi
            done
        echo

        echo "===== PROCESS COUNT GROUPED BY COMMAND ====="
        ps -eo comm= 2>/dev/null | sort | uniq -c | sort -nr | head -100
        echo

        echo "===== THREAD COUNT GROUPED BY PROCESS ====="
        ps -eo pid=,ppid=,nlwp=,comm=,args= --sort=-nlwp 2>&1 | head -100
        echo

        echo "===== FULL THREAD LIST ====="
        # -eL is used instead of the previously failing -eLf/-o combination.
        ps -eL -o pid,ppid,lwp,nlwp,user,psr,stat,rss,vsz,comm,args 2>&1 |
            head -5000
        echo

        echo "===== PROCESS TREE ====="
        ps -eo pid,ppid,user,nlwp,rss,vsz,stat,comm,args --forest 2>&1 |
            head -5000
        echo

        echo "===== /proc STATUS OF TOP THREAD PROCESSES ====="
        ps -eo pid=,nlwp= --sort=-nlwp 2>/dev/null |
            head -20 |
            while read -r process_pid thread_count; do
                if [[ "$process_pid" =~ ^[0-9]+$ ]] &&
                   [[ -r "/proc/$process_pid/status" ]]; then
                    echo
                    echo "------------------------------------------------------------"
                    echo "PID:  $process_pid"
                    echo "NLWP: $thread_count"
                    echo "------------------------------------------------------------"
                    grep -E '^(Name|Pid|PPid|Threads|VmPeak|VmSize|VmRSS|RssAnon|RssFile|RssShmem|VmData|VmStk|VmExe|VmLib|VmPTE|VmSwap|voluntary_ctxt_switches|nonvoluntary_ctxt_switches):' \
                        "/proc/$process_pid/status" 2>/dev/null
                fi
            done
        echo

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

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

        echo "===== SLAB SUMMARY ====="
        if command -v slabtop >/dev/null 2>&1; then
            slabtop -o -s c 2>&1 | head -100
        elif [[ -r /proc/slabinfo ]]; then
            head -200 /proc/slabinfo
        else
            echo "/proc/slabinfo is not readable"
        fi
        echo

        echo "===== PRESSURE STALL INFORMATION ====="
        for pressure_file in /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory; do
            if [[ -r "$pressure_file" ]]; then
                echo "--- $pressure_file ---"
                cat "$pressure_file"
            fi
        done
        echo

        echo "===== DMESG MEMORY / OOM ====="
        dmesg --ctime 2>/dev/null |
            grep -Ei 'memory|oom|out of memory|killed process|page allocation|fork|clone|resource temporarily unavailable|slab' |
            tail -300
        echo

        if command -v journalctl >/dev/null 2>&1; then
            echo "===== JOURNAL LAST 5 MINUTES ====="
            journalctl --since "-5 min" --no-pager 2>&1 | tail -500
            echo
        fi

        echo "===== FILESYSTEM ====="
        df -h
        echo
        echo "===== INODE USAGE ====="
        df -i
        echo
        echo "===== UPTIME ====="
        uptime
        echo
        echo "===== SNAPSHOT END ====="
        echo "Time: $(date '+%F %T')"
    } > "$snap"

    rm -f -- "$fast_threads" "$fast_processes"
    echo "$(date '+%F %T') EVENT snapshot written: $snap" >> "$MAINLOG"
}

cleanup_old_logs

PREV_FREE="$(get_memfree)"
PREV_AVAILABLE="$(get_memavailable)"
PREV_TASKS="$(get_task_count)"

while true; do
    CURRENT_FREE="$(get_memfree)"
    CURRENT_AVAILABLE="$(get_memavailable)"
    CURRENT_TASKS="$(get_task_count)"
    CURRENT_ANON="$(get_anonpages)"
    CURRENT_PAGETABLES="$(get_pagetables)"
    CURRENT_KERNELSTACK="$(get_kernelstack)"

    log_basic_snapshot

    DROP_FREE=0
    DROP_AVAILABLE=0
    TASK_JUMP=0

    if [[ "$PREV_FREE" =~ ^[0-9]+$ && "$CURRENT_FREE" =~ ^[0-9]+$ ]]; then
        DROP_FREE=$((PREV_FREE - CURRENT_FREE))
    fi
    if [[ "$PREV_AVAILABLE" =~ ^[0-9]+$ && "$CURRENT_AVAILABLE" =~ ^[0-9]+$ ]]; then
        DROP_AVAILABLE=$((PREV_AVAILABLE - CURRENT_AVAILABLE))
    fi
    if [[ "$PREV_TASKS" =~ ^[0-9]+$ && "$CURRENT_TASKS" =~ ^[0-9]+$ ]]; then
        TASK_JUMP=$((CURRENT_TASKS - PREV_TASKS))
    fi

    TRIGGER=0
    REASONS=""

    if (( DROP_FREE >= DROP_THRESHOLD_KB )); then
        TRIGGER=1
        REASONS+="MemFree drop $((DROP_FREE / 1024)) MB; "
    fi
    if (( DROP_AVAILABLE >= AVAILABLE_DROP_THRESHOLD_KB )); then
        TRIGGER=1
        REASONS+="MemAvailable drop $((DROP_AVAILABLE / 1024)) MB; "
    fi
    if (( TASK_JUMP >= TASK_JUMP_THRESHOLD )); then
        TRIGGER=1
        REASONS+="Task jump +$TASK_JUMP; "
    fi
    if (( CURRENT_TASKS >= TASK_ABSOLUTE_THRESHOLD )); then
        TRIGGER=1
        REASONS+="Task count $CURRENT_TASKS; "
    fi
    if (( CURRENT_AVAILABLE <= AVAILABLE_LOW_KB )); then
        TRIGGER=1
        REASONS+="MemAvailable low $((CURRENT_AVAILABLE / 1024)) MB; "
    fi

    if (( TRIGGER == 1 )); then
        NOW="$(date +%s)"
        SINCE_LAST=$((NOW - LAST_SNAPSHOT_TIME))

        if (( SINCE_LAST >= COOLDOWN_SECONDS )); then
            {
                echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
                echo "$(date '+%F %T') MEMORY / TASK EVENT DETECTED"
                echo
                echo "Reason: $REASONS"
                echo
                echo "Previous MemFree:       $((PREV_FREE / 1024)) MB"
                echo "Current  MemFree:       $((CURRENT_FREE / 1024)) MB"
                echo "MemFree drop:           $((DROP_FREE / 1024)) MB"
                echo
                echo "Previous MemAvailable:  $((PREV_AVAILABLE / 1024)) MB"
                echo "Current  MemAvailable:  $((CURRENT_AVAILABLE / 1024)) MB"
                echo "MemAvailable drop:      $((DROP_AVAILABLE / 1024)) MB"
                echo
                echo "Previous Tasks:         $PREV_TASKS"
                echo "Current  Tasks:         $CURRENT_TASKS"
                echo "Task increase:          $TASK_JUMP"
                echo
                echo "AnonPages:              $((CURRENT_ANON / 1024)) MB"
                echo "PageTables:             $((CURRENT_PAGETABLES / 1024)) MB"
                echo "KernelStack:            $((CURRENT_KERNELSTACK / 1024)) MB"
                echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
            } >> "$MAINLOG"

            LAST_SNAPSHOT_TIME="$NOW"
            log_detailed_snapshot "$REASONS"
        fi
    fi

    PREV_FREE="$CURRENT_FREE"
    PREV_AVAILABLE="$CURRENT_AVAILABLE"
    PREV_TASKS="$CURRENT_TASKS"
    sleep "$INTERVAL"
done

OliverIO

@Homoran

wieder die bisherigen logdateien löschen und dann

den service neu starten

  sudo chmod +x /usr/local/sbin/memwatch.sh
  sudo systemctl restart memwatch.service
  systemctl status memwatch.service

openai ist wohl gerade überlastet. konnte die dateien über chatgpt nicht hochladen. musste zu codex cli lokal wechseln

Homoran

@OliverIO sagte:

leider mit noch nicht ganz so eindeutigen hinweisen.

Ich hätte jetzt was neues für dich
Die snapshots kommen im minutentakt

snapshot_20260831_153941.log snapshot_20260831_153921.log snapshot_20260831_153841.log snapshot_20260831_153541.log snapshot_20260831_153440.log snapshot_20260831_153339.log snapshot_20260831_153309.log snapshot_20260831_153240.log snapshot_20260831_153140.log snapshot_20260831_153040.log 1540memory.log

Ich sehe mir jetzt sofort deine Vorschläge an

Homoran

So,
Neues Programm läuft!

Dwd.0 hat wohl Probleme mit der gesicherten Verbindung.
Das hatte das log zugespammt.

Ich glaube da wurde nur das logging deaktiviert.

Dwd ist scheduled, daher due Aussage "direkt nach dem start...."

Homoran

Ich will nicht zu viel schicken!
Hier mit neuem Programm und hoher load

Hier ist grün die load!!
Bis zum Anschlag

Und logs noch und nöcher
snapshot_20260831_160141.log snapshot_20260831_160241.log snapshot_20260831_160346.log snapshot_20260831_160451.log snapshot_20260831_160542.log snapshot_20260831_155944.log

1606memory.log

Ich würde erst wieder etwas senden, wenn deine KI mehr Informationen braucht oder der iob gekillt wurde

*DANKE!!K

OliverIO

@Homoran

da war jetzt nur das um 1605 mit dem neuen skript von den snapshots.
wir sammeln noch ein wenig.
gut, der höher load kommt nun auch ein wenig von dem skript

ohne bisher die ki zu fragen ist mir aber an den letzten snapshots bspw beim
1788185456278-snapshot_20260831_153339.log
folgendes aufgefallen

 285056   39891 iobroker    7  0.6 49664 751040 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"system.host.ioBrokerpi5.freemem","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.freeMem17881832179450.39450520995403915","round":null,"logDebug":false}
 285057   39891 iobroker    7  0.6 49568 554320 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"Messwerte.0.HardwareDaten.Master.Speicher.mem_free","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"Messwerte.0.HardwareDaten.Master.Speicher.mem_free17881832179480.4657008882857676","round":null,"logDebug":false}
 285059   39891 iobroker    7  0.6 49584 750816 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"alias.0.Host.memAvailable","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.memAvailable17881832179540.45382242273599815","round":null,"logDebug":false}
 285064   39891 iobroker    7  0.5 49104 617424 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered","path":"/mnt/usbplatte/data/history/","start":1788161558739,"end":1788183158739,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"minmax","limit":300,"addId":false,"sessionId":1056,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered17881832179590.4791995853762201","round":null,"logDebug":false}
 285071   39891 iobroker    7  0.6 49680 685296 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"system.host.ioBrokerpi5.freemem","path":"/mnt/usbplatte/data/history/","start":1788161558741,"end":1788183158741,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1057,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.freeMem17881832179680.021342402309211916","round":null,"logDebug":false}
 285077   39891 iobroker    7  0.6 49600 750816 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"alias.0.Host.memAvailable","path":"/mnt/usbplatte/data/history/","start":1788161558741,"end":1788183158741,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"min","limit":300,"addId":false,"sessionId":1057,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"alias.0.Host.memAvailable17881832179820.20277489329472664","round":null,"logDebug":false}
 285093   39891 iobroker    7  0.5 49104 617424 Sl   Mon Aug 31 15:33:37 2026 node            /usr/bin/node --max-old-space-size=1700 /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {"id":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered","path":"/mnt/usbplatte/data/history/","start":1788161558741,"end":1788183158741,"count":300,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"minmax","limit":300,"addId":false,"sessionId":1057,"returnNewestEntries":false,"integralInterpolation":null,"removeBorderValues":false,"logId":"Messwerte.0.HardwareDaten.Master.Speicher.memBuffered17881832179950.6046703034490128","round":null,"logDebug":false}

davon gibt es noch mehr zeilen und wahrscheinlich sind das nicht alle, da das skript nur die ersten paar aufzeichnet.

jede zeile ist ein eigener task
den einzigen kandidaten hab ich hier gefunden
https://github.com/ioBroker/ioBroker.history/blob/6957d59c009494caf798bea9fb32fe57c8b17f53/src/lib/getHistory.ts#L142
da scheint wohl node solche operationen als eigenen task auszuführen.
Das ist die Stelle bei der der history adapter die tagesdatei zu einem Datenpunkt liest.

aber wie weiter oben schon mal erwähnt und zu überprüfen:
zeichnest du insbesondere bei den speicherrelevanten datenpunkten JEDE Änderung auf?
ich weiß nicht in welchem zeittakt der iobroker intern die datenpunkte aktualisiert. die gehen dann ja auch in die history und wenn da alle paar millisekunden bzw 100 millisekunden eine änderung gibt, dann werden entsprechend viele dateien geöffnet.
gut der history adapter sammelt ein wenig die daten in einem cache, aber wenn der voll ist, muss er schreiben.

OliverIO

@Homoran sagte:

Ich würde erst wieder etwas senden, wenn deine KI mehr Informationen braucht oder der iob gekillt wurde

sende insbesondere die snapshot, die größer wie 200k sind.
wenn ein oom kill dabei ist umso besser

Homoran

@OliverIO sagte:

da scheint wohl node solche operationen als eigenen task auszuführen.

Aaah, das passt!

Unter top tauchte ab und zu ei prozess "node" auf und verschwand sofort wieder

@OliverIO sagte:

die gehen dann ja auch in die history und wenn da alle paar millisekunden bzw 100 millisekunden

Nein, die sind nur höchstens alkec6 Sekunden.

Da müsste ich die system.host und system.adapter DP sicherheitshalber mal mit einer Blockzeit belegen!
Danke für den Tipp

@OliverIO sagte:

da war jetzt nur das um 1605 mit dem neuen skript von den snapshots.

Dann hab ich vielleicht die falschen hochgeladen.
Muss ich checken und tausche ggf. Aus

@OliverIO sagte:

sende insbesondere die snapshot, die größer wie 200k sind.
wenn ein oom kill dabei ist umso besser

Ok!
Damit kann ich was anfangen

Community Forum

NEWS

Load average am Anschlag -> Neustart

Analyse der memwatch-Logs vom 31.08.2026

Kurzfazit

Ausgewertete Dateien

Erkannte Ereignisse

Detailanalyse des Ereignisses um 14:21:36

Die anderen beiden Ereignisse

14:05:43

14:17:01

Weitere relevante Beobachtungen

Fehler und Lücken im aktuellen Messskript

1. Parent-Auswertung bricht ab

2. FULL THREAD LIST ist leer

3. Snapshot-Erfassung dauert etwa fünf Sekunden

4. Taskzahl im Trigger und Snapshot unterscheiden sich

Bewertung der wahrscheinlichsten Ursache

Empfohlene nächste Schritte

Gesamtergebnis

Analyse der memwatch-Logs vom 31.08.2026

Kurzfazit

Ausgewertete Dateien

Erkannte Ereignisse

Detailanalyse des Ereignisses um 14:21:36

Die anderen beiden Ereignisse

14:05:43

14:17:01

Weitere relevante Beobachtungen

Fehler und Lücken im aktuellen Messskript

1. Parent-Auswertung bricht ab

2. FULL THREAD LIST ist leer

3. Snapshot-Erfassung dauert etwa fünf Sekunden

4. Taskzahl im Trigger und Snapshot unterscheiden sich

Bewertung der wahrscheinlichsten Ursache

Empfohlene nächste Schritte

Gesamtergebnis

Support us

443

33.0k

83.7k

1.3m

2. `FULL THREAD LIST` ist leer

2. `FULL THREAD LIST` ist leer