Load average am Anschlag -> Neustart

OliverIO

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

Homoran

@OliverIO sagte:

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

Geändert!

@OliverIO sagte:

die snapshot, die größer wie 200k sind.

sind sie alle bisher!
Sort by size:

Nicht chronologisch!
Was darf's sein?

OliverIO

@Homoran sagte:

Nein, die sind nur höchstens alkec6 Sekunden.

hm, du siehst allein in dem kleinen ausschnitt den ich beispielhaft gepostet habe ist mehrfach
system.host.ioBrokerpi5.freemem
Messwerte.0.HardwareDaten.Master.Speicher.mem_free
Messwerte.0.HardwareDaten.Master.Speicher.memBuffered
alles in der gleichen sekunde enthalten.
der exakte trigger lässt sich nicht ermitteln, da ja einmal der history adapter wegen schreiben liest und aber auch deine diagramme (womöglich in mehreren diagrammen den gleichen datenpunkt mehrfach) ebenfalls lesen.
aber alle fragen die history adapter funktionalität

ich will es nur nochmal erwähnen. eine datenbank für die history werte würde das wahrscheinlich entschärfen.

aber jetzt schauen wir mal auf die nächsten snapshots bevor man vorschnell entscheidungen trifft. passe erst mal auch NICHT den history intervall deiner datenpunkte an, sonst ist ggfs die grundlage der analyse weg um entscheiden zu können.

paul53

@Homoran [sagte]: Unter top tauchte ab und zu ei prozess "node" auf und verschwand sofort wieder

Das passiert immer dann, wenn "node" einen neuen Prozess (Instanz / Skript) compiliert und startet.

OliverIO

@paul53 @homoran

der Ausschnitt ist aus dem Abschnitt
===== PROCESSES WITH MOST THREADS =====

Ich denke threads sieht man unter top nicht.

Homoran

@OliverIO sagte:

hm, du siehst allein in dem kleinen ausschnitt den ich beispielhaft gepostet habe ist mehrfach
system.host.ioBrokerpi5.freemem
Messwerte.0.HardwareDaten.Master.Speicher.mem_free
Messwerte.0.HardwareDaten.Master.Speicher.memBuffered

Die rufe ich per 15sec. Cron und dann mit exec ab.

Wo die mehrfach pro sekunde herkommen ist mir schleierhaft

Edit:
Lesen in der history ist möglich.
Könnte das beim zoomen passieren....

...oder eventuell bei mehrfachem Einlesen, weil der Browser Kontakt verliert
Auch die sockets wurden mehrfach pro sekunde neu verbunden

OliverIO

@Homoran

ich weiß nicht wie die diagramme auf aktualisierung der datenpunkte reagieren.
zu vermuten ist, das wenn sich der datenpunkt ändert, das diagramm die history abruft. wenn der datenpunkt in mehreren diagrammen auftaucht, dann sind das auch verschiedene lesevorgänge.

Homoran

@OliverIO sagte:

ich weiß nicht wie die diagramme auf aktualisierung der datenpunkte reagieren.
zu vermuten ist, das wenn sich der datenpunkt ändert, das diagramm die history abruft. wenn der datenpunkt in mehreren diagrammen auftaucht, dann sind das auch verschiedene lesevorgänge

Jein!
Du kannst in den charts einen Zeitraum für den refresh einstellen.

Natürlich wird beim neuladen/zoomen auch neu abgerufen, weil auch anders aggregiert wird.
Das hat immer schon zu mehr Last geführt.
Bei sehr komplexen Charts und mehreren Zoomversuchen am Tablet/Handy ist es auch früher mal!! zum Absturz gekommen.
Aber vielleicht 2x im Jahr!

Im Moment spiele ich natürlich viel an den Charts, um Zusammenhänge zu sehen.
Das lenkt dann vielleicht vom eigentlichen Problem ab.
Da sollten wir nur Drops beachten, die nachts passieren.

Hier die letzten 3 ganz großen Snapshots
snapshot_20260831_162341.log snapshot_20260831_162442.log snapshot_20260831_163935.log

OliverIO

@Homoran

memory.log
noch bitte

Homoran

@OliverIO hier
1853memory.log

OliverIO

@Homoran

also mit meiner Vermutung lag ich richtig.
hier die Analyse.
Ich habe dem codex nichts von dem was ich vorhin geschrieben habe mitgeteilt. einfach nur hier neue dateien.

hast du mehrere browserclients laufen?
jeder fragt natürlich auch wieder separat ab und löst eine neue getHistory aus.

Folgeanalyse der memwatch-Daten vom 31.08.2026

Kurzfazit

Die neuen Snapshots identifizieren den Verursacher der Task- und
Speicherstürme eindeutig:

io.history.0 (PID 39891) startet gleichzeitig sehr viele separate
Node-Prozesse mit iobroker.history/build/lib/getHistory.js.

Jeder dieser Prozesse besitzt typischerweise sieben Threads und ungefähr
40 bis 57 MB RSS. Bei 76 bis 156 gleichzeitig aktiven getHistory.js-Prozessen
entstehen deshalb innerhalb weniger Sekunden mehrere hundert bis über tausend
zusätzliche Tasks und ein Speicherbedarf von mehreren Gigabyte. Im zweiten
Snapshot sind zusätzlich 112 nicht abgeholte Zombie-Prozesse ([node] <defunct>) sichtbar.

Der zuvor verdächtigte Adapter dwd.0 ist damit als Hauptursache widerlegt.
Die unmittelbare technische Ursache liegt im History-Adapter beziehungsweise
in einer extrem hohen Zahl paralleler History-Abfragen. Welcher Client oder
welches ioBroker-Script diese Abfragen auslöst, lässt sich aus den gelieferten
System-Snapshots allein noch nicht endgültig bestimmen.

Ausgewertete neue Dateien

1788195273188-1853memory.log
1788190003254-snapshot_20260831_162341.log
1788190003258-snapshot_20260831_162442.log
1788190003266-snapshot_20260831_163935.log

Das große memory.log enthält zahlreiche weitere Trigger. Für drei Ereignisse
wurden detaillierte Snapshots mitgeliefert; diese drei erlauben die eindeutige
Prozesszuordnung.

Übersicht der drei detaillierten Ereignisse

Snapshotzeit	MemAvailable-Abfall	Taskanstieg	Tasks am Trigger	aktive `getHistory.js`	Zombies	Threads der aktiven History-Children
16:23:42	1.859 MB	+955	1.669	156	0	1.092
16:24:43	1.103 MB	+525	1.239	76	112	532
16:39:36	1.283 MB	+829	1.487	141	3	987

Die Zahlen passen sehr genau zusammen: 156 aktive Child-Prozesse mit jeweils
sieben Threads ergeben 1.092 Threads. Zusammen mit den ungefähr 700 normalen
Systemtasks erklärt das vollständig die am Trigger beziehungsweise unmittelbar
danach beobachtete Größenordnung.

Eindeutige Parent-Zuordnung

In allen drei Soforterfassungen ist der Parent der massenhaft erzeugten
Prozesse:

PID 39891  io.history.0

Beispiele seiner Children sehen so aus:

/usr/bin/node --max-old-space-size=1700 \
  /opt/iobroker/node_modules/iobroker.history/build/lib/getHistory.js {...}

Die Parent-Gruppierung ergibt:

um 16:23:42: 156 Prozesse mit PPID 39891,
um 16:24:43: 188 Prozesse mit PPID 39891,
um 16:39:36: 144 Prozesse mit PPID 39891.

Beim mittleren Snapshot bestehen diese 188 Children aus 76 noch aktiven
getHistory.js-Prozessen und 112 Zombies. Das beweist auch, dass der
History-Prozess zu diesem Zeitpunkt beendete Child-Prozesse nicht schnell genug
mit wait() beziehungsweise über seinen Child-Exit-Handler aufgeräumt hatte.

Speicherwirkung

Die aufsummierten RSS-Werte der aktiven getHistory.js-Prozesse betragen in den
drei Soforterfassungen rechnerisch ungefähr:

8.171 MB bei 156 aktiven Prozessen,
3.828 MB bei 76 aktiven Prozessen,
7.094 MB bei 141 aktiven Prozessen.

Diese RSS-Summen dürfen wegen gemeinsam genutzter Speicherseiten nicht als
exakter physischer RAM-Verbrauch interpretiert werden. Die gleichzeitig
gemessenen realen Einbrüche von MemAvailable um 1,1 bis 1,9 GB zeigen aber,
dass ein großer privater Speicheranteil tatsächlich angelegt wird. Die
Parallelität reicht auf dem 8-GB-System aus, um die früher beobachteten
OOM-Ereignisse zu erklären.

Jeder Child-Prozess darf außerdem mit folgendem Parameter theoretisch einen
sehr großen Node-Heap anlegen:

--max-old-space-size=1700

Ein einzelner Prozess nutzt dieses Maximum hier nicht aus. Bei über hundert
gleichzeitigen Prozessen ist diese Konfiguration jedoch keine wirksame
Gesamtbegrenzung.

Muster der History-Abfragen

Es handelt sich nicht um einzelne, sehr große Abfragen, sondern um viele
parallel wiederholte Abfragen. Typische Parameter sind:

{
  "count": 1500,
  "aggregate": "minmax",
  "limit": 1500,
  "start": 1788127200000,
  "end": 1788213600000
}

Mehrere identische Datenpunkte werden gleichzeitig oder in rasch aufeinander
folgenden Sessions wiederholt abgefragt. Beispiele aus den Snapshots:

system.host.ioBrokerpi5.freemem
system.host.ioBrokerpi5.inputCount
system.host.ioBrokerpi5.outputCount
system.host.ioBrokerpi5.load
system.adapter.javascript.1.inputCount
system.adapter.javascript.1.outputCount
Messwerte.0.HardwareDaten.Master.CPU_Last.CPU_Temp
Messwerte.0.Solaranlage.Momentanwerte.Solarestimate2
Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell
Messwerte.0.Solaranlage.Momentanwerte.Eigenverbrauch
Messwerte.0.Stromzaehler.Momentanwerte.akt_Verbrauch
Messwerte.0.Stromzaehler.Momentanwerte.akt_Einspeisung
Messwerte.0.Batterie.Ladung
Messwerte.0.Batterie.Entladung
alias.0.Stromzaehler.Bezug_aktuell
modbus.1.inputRegisters.226.789_Solar_PV_power

Im Snapshot um 16:39 werden beispielsweise sieben System-/Hardware-Datenpunkte
jeweils ungefähr 19- bis 20-mal parallel angefragt. In den Prozessargumenten
steigen dabei auch die sessionId-Werte fortlaufend an. Das sieht nach
wiederholten Anfragegruppen eines Dashboards, Diagramms oder Scripts aus und
nicht nach einer normalen Einzelabfrage.

Ursache und Auslöser getrennt betrachtet

Technische Ursache: bestätigt

Der History-Adapter erzeugt für jede History-Abfrage einen eigenen
getHistory.js-Child-Prozess. Zu viele gleichzeitige Abfragen führen direkt zu:

hunderten Node-Prozessen,
sieben Threads pro aktivem Prozess,
massiv steigenden PageTables und KernelStack,
mehreren Gigabyte zusätzlichem Speicherbedarf,
kurzzeitig hoher CPU- und I/O-Last,
Zombies, wenn Children schneller enden als sie abgeholt werden,
im Extremfall OOM-Kills.

Anfragender Client: noch nicht abschließend identifiziert

PPID 39891 beweist, dass io.history.0 die Prozesse startet. Die Argumente der
Children enthalten jedoch nicht den Namen des Clients, der die History-Anfrage
an den Adapter geschickt hat. Wahrscheinliche Quellen sind:

ein geöffnetes VIS-/VIS-2-Dashboard mit vielen oder zyklisch neu gerenderten
Diagrammen,
ein Flot-/ECharts-/Chart-Widget mit zu kurzem Refresh-Intervall,
ein JavaScript unter javascript.1, das viele getHistory-Aufrufe startet,
ohne deren Abschluss abzuwarten,
eine Schleife oder ein mehrfach registrierter Timer/Listener, der dieselben
Abfragegruppen immer wieder startet.

Die Datenpunktgruppen wirken wie Dashboard- oder Energievisualisierungsdaten.
Das ist ein starker Hinweis, aber noch kein Beweis für einen bestimmten Client.

Korrektur der vorherigen Bewertung

In der ersten Analyse war dwd.0 aufgrund seines Startzeitpunkts der stärkste
damals sichtbare Verdächtige. Die frühere Threadliste kam zu spät und war zudem
teilweise leer. Die reparierte Soforterfassung zeigt nun den tatsächlichen
Mechanismus. dwd.0 erklärt die neuen Peaks nicht; seine zeitliche Nähe im
früheren Snapshot war eine Korrelation ohne Kausalitätsnachweis.

Dringend empfohlene Maßnahmen

1. System kurzfristig stabilisieren

Betroffene Visualisierung beziehungsweise das verdächtige Script schließen
oder deaktivieren.
Falls der Sturm gerade läuft, io.history.0 kontrolliert neu starten, damit
aktive Children und Zombies verschwinden.
Danach beobachten, ob die Taskzahl wieder stabil bei ungefähr 650 bis 720
bleibt.

Ein Neustart behandelt nur die Symptome. Ohne Beseitigung des Anfrageerzeugers
wird der Sturm erneut auftreten.

2. Anfragequelle per A/B-Test ermitteln

In dieser Reihenfolge jeweils nur eine Änderung vornehmen und memory.log
beobachten:

Alle Browser mit ioBroker-Visualisierungen schließen.
Falls die Peaks aufhören, Browser/Views einzeln wieder öffnen.
Falls sie weiterlaufen, verdächtige JavaScript-Instanz beziehungsweise
einzelne Scripts deaktivieren.
Besonders nach Scripts suchen, die sendTo('history.0', 'getHistory', ...),
getHistory(...) oder periodische Chart-Aktualisierungen verwenden.
Timer, setInterval, State-Subscriptions und rekursive Aktualisierungen
darauf prüfen, ob bei jedem Lauf neue Abfragen gestartet werden, bevor alte
abgeschlossen sind.

3. Parallelität begrenzen

Beim eigentlichen Aufrufer sollten History-Abfragen:

nicht mehrfach parallel für denselben Datenpunkt laufen,
erst nach Abschluss der vorherigen Anfrage erneut gestartet werden,
in einer begrenzten Queue verarbeitet werden,
gecacht oder zusammengefasst werden,
mit einem deutlich längeren Aktualisierungsintervall laufen.

Schon eine Begrenzung auf wenige gleichzeitige Abfragen würde den Task- und
Speicherpeak drastisch reduzieren.

4. History-Adapter prüfen und aktualisieren

Installierte Version von iobroker.history feststellen.
Changelog und bekannte Probleme dieser konkreten Version bezüglich
getHistory.js, Child-Prozessen, Parallelität und Zombies prüfen.
Ein Update erst nach Versions- und Kompatibilitätsprüfung durchführen.

Die Systemdaten belegen eine problematische Last, sagen aber nicht, ob die
eingesetzte Adapterversion bereits eine eingebaute Parallelitätsbegrenzung
anbietet oder ob es dazu einen bekannten Fix gibt.

Sinnvolle Zusatzdiagnose

Für die eindeutige Identifikation des anfragenden Clients sollten unmittelbar
um einen Peak zusätzlich gesichert werden:

iobroker logs --watch

und gezielt:

grep -RniE "getHistory|sendTo.*history\.0|history\.0.*getHistory" \
  /opt/iobroker/iobroker-data/files \
  /opt/iobroker/node_modules 2>/dev/null

Bei JavaScript-Quelltexten sollte bevorzugt über die ioBroker-Objekte oder den
Admin exportiert/gesucht werden, weil nicht jedes Script als normale Datei
vorliegt.

Zusätzlich wäre eine kurze Liste der geöffneten VIS-Views und der aktiven
Chart-Widgets zum Peakzeitpunkt hilfreich. Die im Prozessargument sichtbaren
sessionId-Gruppen könnten dann einer konkreten Browser-/Widget-Sitzung
zugeordnet werden, sofern der Adapter im Debug-Log die Session protokolliert.

Endergebnis

Die Diagnose ist jetzt wesentlich belastbarer als zuvor. Es handelt sich nicht
um einen einzelnen Node-Prozess mit tausenden Threads, sondern um einen
Prozesssturm aus bis zu 156 gleichzeitig aktiven getHistory.js-Prozessen.
Diese werden alle von io.history.0 erzeugt und besitzen jeweils sieben
Threads. Wiederholte parallele History-Anfragegruppen sind damit die bestätigte
Ursache für die Task-, PageTable-, KernelStack- und RAM-Spitzen.

Der nächste Untersuchungsschritt sollte nicht mehr allgemein nach einem
Speicherleck suchen, sondern gezielt den Client beziehungsweise das Script
finden, das diese History-Abfragen in hoher Parallelität auslöst.

Homoran

@OliverIO sagte:

sondern gezielt den Client beziehungsweise das Script
finden, das diese History-Abfragen in hoher Parallelität auslöst.

Üblicherweise ist das ein Client.

Deswegen irritiert mich das so.
Das hat jahrelang so funktioniert.
Außerdem:

@OliverIO sagte:

system.host.ioBrokerpi5.freemem
system.host.ioBrokerpi5.inputCount

system.adapter.javascript.1.inputCount
system.adapter.javascript.1.outputCount

Sind erst nach dem Auftreten der Probleme hinzugekommen!

@OliverIO sagte:

jeweils ungefähr 19- bis 20-mal parallel angefragt

Dafür habe ich keine Erklärung

Auch nicht dass der Absturz üblicherweise stattfindet wenn kein client aktiv ist.

Wie ich ganz zu Beginn schon zeigte

Verbindet/trennt sich der client (...116, das ist mein Tablet) auch mehrfach pro Sekunde.
Das wäre vielleicht die Ursache der im log festgehaltenen Phänomene, ohne dass das die wirklichen Ursachen sind.

Ich bin ratlos

OliverIO

@Homoran

um clients dann ausschließen mal eine weile alle browser tabs auf allen geräten mit iobroker schließen und schauen ob diese große Anzahl an threads noch auftauchen.

du nutzt vis1 oder vis2 als visualisierung?

dann auch mal PC browser und tablet vergleichen. also nur PC browser geöffnet und tablet nicht und umgekehrt.
Nicht das bspw das tablet ständig in schlafmodus geht und gleich wieder aufwacht. das löst evtl auch eine aktualisierung aus.
jeder einzelne tab zählt auch als separater client

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

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

Folgeanalyse der memwatch-Daten vom 31.08.2026

Kurzfazit

Ausgewertete neue Dateien

Übersicht der drei detaillierten Ereignisse

Eindeutige Parent-Zuordnung

Speicherwirkung

Muster der History-Abfragen

Ursache und Auslöser getrennt betrachtet

Technische Ursache: bestätigt

Anfragender Client: noch nicht abschließend identifiziert

Korrektur der vorherigen Bewertung

Dringend empfohlene Maßnahmen

1. System kurzfristig stabilisieren

2. Anfragequelle per A/B-Test ermitteln

3. Parallelität begrenzen

4. History-Adapter prüfen und aktualisieren

Sinnvolle Zusatzdiagnose

Endergebnis

Folgeanalyse der memwatch-Daten vom 31.08.2026

Kurzfazit

Ausgewertete neue Dateien

Übersicht der drei detaillierten Ereignisse

Eindeutige Parent-Zuordnung

Speicherwirkung

Muster der History-Abfragen

Ursache und Auslöser getrennt betrachtet

Technische Ursache: bestätigt

Anfragender Client: noch nicht abschließend identifiziert

Korrektur der vorherigen Bewertung

Dringend empfohlene Maßnahmen

1. System kurzfristig stabilisieren

2. Anfragequelle per A/B-Test ermitteln

3. Parallelität begrenzen

4. History-Adapter prüfen und aktualisieren

Sinnvolle Zusatzdiagnose

Endergebnis

Support us

443

33.0k

83.7k

1.3m

2. `FULL THREAD LIST` ist leer