Monatsrückblick Juli / August 2026 ist online!

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

[Homoran]

@paul53 sehe ich genau so!
Danke

[Homoran]

############################################################
MEMORY EVENT SNAPSHOT
Time: 2026-08-31 09:08:06
############################################################

===== /proc/meminfo =====
MemTotal:        8255872 kB
MemFree:         2220016 kB
MemAvailable:    2643200 kB
Buffers:          158848 kB
Cached:           346800 kB
SwapCached:          672 kB
Active:          3010608 kB
Inactive:        1408752 kB
Active(anon):    2806336 kB
Inactive(anon):  1110944 kB
Active(file):     204272 kB
Inactive(file):   297808 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       2097136 kB

Da scheint jetzt schon der nächste event zu sein

Edit

############################################################
MEMORY EVENT SNAPSHOT
Time: 2026-08-31 09:45:01
############################################################

===== /proc/meminfo =====
MemTotal:        8255872 kB
MemFree:          386752 kB
MemAvailable:     650272 kB
Buffers:           34720 kB
Cached:            94336 kB
SwapCached:          592 kB
Active:          2235792 kB
Inactive:        3726624 kB
Active(anon):    2164832 kB
Inactive(anon):  3671312 kB
Active(file):      70960 kB
Inactive(file):    55312 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       2097136 kB

Edit2
Falls die KI was aktuelles dazu sehen will

Noch ein snapshot

############################################################
MEMORY EVENT SNAPSHOT
Time: 2026-08-31 09:49:56
############################################################

===== /proc/meminfo =====
MemTotal:        8255872 kB
MemFree:         2163712 kB
MemAvailable:    2516336 kB
Buffers:           43760 kB
Cached:           175776 kB
SwapCached:          512 kB
Active:          2481600 kB
Inactive:        1401344 kB
Active(anon):    2393040 kB
Inactive(anon):  1273184 kB
Active(file):      88560 kB
Inactive(file):   128160 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       2097136 kB

Den dazugehörigen drop hab ich gar nicht wirklich als "bedrohlich" registriert.

[Ro75]

Und mal ganz doof gefragt. Kann es sein, dass der PI5 selbst eine Macke hat?

Ro75.

[Homoran]

@Ro75 möchlich ist alles!

Aber dann hätte der andere wahrscheinlich die selbe Macke.
Dort traten due Abstürze zuerst auf.
Weil wir kurz vorher Stromausfall hatten und da immer noch bookworm drauf lief, bin ich dann auf den neuen mit Trixie umgezogen, alles neu installiert, backup restored, dadurch Pakete neu gepackt, aber die Probleme blieben

[Ro75]

Also betrifft es letztlich 2 Pi's. Schon mal einen mit Ubuntu versucht?

Ro75.

[OliverIO]

@Homoran

Das sieht nicht vollständig aus.
Das ist nur der Mem Info Bereich
Kannst du bitte mal die Befehle, die ich oben aufgelistet hab ausprobieren ob die auch da sind?

[Homoran]

@Ro75 sagte:

Schon mal einen mit Ubuntu versucht?

Nein!
Hab aber schon drüber nachgedacht.

Hab aber "eigentlich" keine Zeit zum experimentieren.

Deswegen wäre ich im Moment mit Symptombehebung zufrieden gewesen.

Die anderen SSD/SD wollte ich als Hardwarebackups halten und nicht überschreiben.

Vielleicht schaffe ich es heute Zeit und Genehmigung für eine Karte und nvme zu bekommen

[Homoran]

@OliverIO recht du hast!
Hab mich auch gewundert

Das sind ja 14 Seiten!

snapshot_20260831_090806.log snapshot_20260831_094501.log snapshot_20260831_094956.log

[OliverIO]

@Homoran

Und das Memory.log noch
Welches den Verlauf zeigt

[Homoran]

@OliverIO sagte:

Und das Memory.log noch

Such ich dir!

Ansonsten hier der Vorrat

Und der chart dazu

Edit
memory.log

Da ist hoffentlich was dabei, die load war die ganze Zeit hoch und kommt jetzt erst wieder zur Ruhe

Muss jetzt weg!

[OliverIO]

@Homoran

hier das ergebnis der analyse

Ja. Die Logs zeigen inzwischen ziemlich eindeutig, in welche Richtung wir suchen müssen.

Der entscheidende Fund ist nicht Cached oder Slab, sondern die explosionsartige Zunahme der Anzahl von Tasks/Threads. Beim Ereignis um 09:45:01 fällt MemFree von etwa 2,5 GB auf 253 MB. Gleichzeitig liegt MemAvailable nur noch bei ca. 515 MB. Das ist also tatsächlich belegter bzw. kurzfristig nicht verfügbarer Speicher und nicht bloß Filesystem-Cache.

Noch deutlicher wird es in /proc/meminfo: AnonPages liegt während des Peaks bei rund 6,0 GB, PageTables bei enormen ~685 MB und KernelStack bei ~39 MB. Cache und Slab sind dagegen relativ klein.

Der eigentliche Fingerzeig steht aber im loadavg:

09:08   1/706
09:45   150/2317
09:49   8/958
10:02   44/1461
10:34   32/2899
10:43   32/2553

Normalerweise hat dein System also ungefähr 700 Tasks. Während der heftigen Ereignisse sind es plötzlich 2.300–2.900 Tasks/Threads.

Das passt hervorragend zu den anderen Werten:

Wert	normal	extremer Peak
Tasks	~700	2.300–2.900
MemFree	~3 GB	200–300 MB
AnonPages	~3,2–3,8 GB	~6 GB
PageTables	~340 MB	~700 MB
KernelStack	~11 MB	~40 MB

Beim späteren Ereignis um 10:43 sieht man beispielsweise unmittelbar AnonPages von rund 3,2 GB auf 6,06 GB, PageTables von rund 344 MB auf 710 MB, KernelStack von rund 11 MB auf 40 MB und gleichzeitig 2.553 Tasks.

Damit ist die Ursache schon erheblich eingegrenzt

Es sieht sehr stark nach einem Process-/Thread-Storm aus.

Irgendein Prozess erzeugt kurzfristig ungefähr 1.500–2.200 zusätzliche Tasks. Das können echte Prozesse oder Threads sein. Dabei entstehen zusätzlich:

• anonymer Prozessspeicher,
• Page Tables,
• Kernel Stacks,
• weitere Kernel-Strukturen.

Und wenige Sekunden später verschwinden die Tasks wieder.

Das erklärt auch perfekt, warum wir in den bisherigen ps-Snapshots keinen 2-GB-Prozess sehen.

Unser bisheriges Script hat genau an dieser Stelle einen Fehler

In log_detailed_snapshot() machen wir momentan:

cat /proc/meminfo
free -h

vmstat 1 5

ps ...

vmstat 1 5 wartet ungefähr fünf Sekunden.

Bei 09:45 passiert deshalb Folgendes: Beim Start des Snapshots sind noch ungefähr 2.300 Tasks vorhanden. Während vmstat läuft, normalisiert sich der Speicher bereits wieder. Die erste vmstat-Messung sieht noch die Situation, danach steigt free sofort wieder massiv an.

Erst danach wird ps ausgeführt.

Dann sind die Tausenden kurzlebigen Prozesse/Threads bereits wieder verschwunden und wir sehen nur die normalen ioBroker-Prozesse. Der Controller selbst hat beispielsweise nur rund 448 MB RSS, javascript.1 rund 278 MB. Keiner davon erklärt den Peak.

Das müssen wir ändern.

Ich würde memwatch.sh jetzt gezielt erweitern

Ganz am Anfang von log_detailed_snapshot() sollten sofort Prozess- und Threadinformationen geschrieben werden, noch bevor free, vmstat, slabtop usw. ausgeführt werden.

Insbesondere diese Befehle:

echo "===== IMMEDIATE PROCESS SNAPSHOT ====="

echo "--- process count ---"
ps -e --no-headers | wc -l

echo "--- task/thread count ---"
ps -eLf --no-headers | wc -l

echo
echo "--- processes with most threads ---"
ps -eo pid,ppid,user,nlwp,rss,vsz,stat,comm,args \
    --sort=-nlwp | head -80

echo
echo "--- processes by RSS ---"
ps -eo pid,ppid,user,nlwp,rss,vsz,stat,comm,args \
    --sort=-rss | head -80

echo
echo "--- process count grouped by parent PID ---"
ps -eo ppid= | sort -n | uniq -c | sort -nr | head -50

echo
echo "--- process count grouped by command ---"
ps -eo comm= | sort | uniq -c | sort -nr | head -50

echo
echo "--- full process tree ---"
ps -eo pid,ppid,user,nlwp,rss,vsz,stat,comm,args --forest

Besonders interessant wird:

ps -eo pid,ppid,user,nlwp,rss,vsz,stat,comm,args --sort=-nlwp

Angenommen, wir sehen beim nächsten Peak:

PID     PPID    NLWP  COMMAND
40099   39859   1650  io.javascript.1

dann hätten wir den Schuldigen praktisch direkt.

Oder:

PID      PPID
123001   40099
123002   40099
123003   40099
...

Dann erzeugt PID 40099 hunderte oder tausende Child-Prozesse.

Oder beispielsweise:

1800 node

in der Gruppierung nach comm, dann wissen wir ebenfalls sofort, was los ist.

Auch die alten OOM-Ereignisse passen ins Bild

In dmesg gibt es sogar bereits zwei echte Out-of-Memory-Ereignisse vom Vorabend bzw. kurz nach Mitternacht. Dabei hat der Kernel jeweils iobroker.js-controller abgeschossen.

Das heißt allerdings nicht, dass der Controller die Ursache war. Der OOM-Killer musste schlicht einen Prozess auswählen. Auffällig ist vielmehr, dass das System offenbar schon vorher durch dasselbe oder ein ähnliches Ereignis tatsächlich bis zum OOM getrieben wurde.

Meine derzeitige Einschätzung

Ich würde die Wahrscheinlichkeit momentan ungefähr so einordnen:

Sehr wahrscheinlich: Ein Prozess erzeugt für wenige Sekunden eine sehr große Anzahl von Prozessen oder Threads.

Wahrscheinlich: Der Ursprung liegt im ioBroker-/Node.js-Umfeld, einfach weil dort sehr viele Prozesse laufen und insbesondere JavaScript-Skripte externe Programme oder Child-Prozesse erzeugen können. Bewiesen ist das aber noch nicht.

Sehr unwahrscheinlich: Filesystem/Page Cache, Slab Leak oder tmpfs. Dafür passen die Messwerte überhaupt nicht.

Ebenfalls unwahrscheinlich: Ein klassischer Memory Leak eines einzelnen ioBroker-Adapters. Dafür ist das Verhalten viel zu abrupt und der Speicher wird unmittelbar wieder frei.

Das Auffälligste ist wirklich diese Kombination:

700 → 2.900 Tasks, AnonPages +~3 GB, PageTables +~350 MB, KernelStack +~30 MB und wenige Sekunden später alles wieder weg.

Das ist fast ein Fingerabdruck eines massiven kurzfristigen Prozess-/Thread-Spawns.

Ich würde daher als nächsten Schritt nicht mehr primär RAM messen, sondern das vorhandene memwatch.sh so umbauen, dass es den Verursacher innerhalb dieser 2–5 Sekunden erwischt. Ich kann dir dafür direkt die komplett überarbeitete Version des Scripts erstellen; dabei würde ich zusätzlich PPID-Gruppierung und Thread-Zahlen einbauen, sodass wir beim nächsten 2–3-GB-Einbruch sehr wahrscheinlich genau sehen, welcher ioBroker-Adapter oder welcher andere Prozess die Tausenden Tasks erzeugt.