Load average am Anschlag -> Neustart
-
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 0available: 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 inMemAvailable.Als Erstes würde ich
/proc/meminfoaufzeichnenAuf dem betroffenen Rechner:
cat /proc/meminfoInteressant sind insbesondere:
MemTotal MemFree MemAvailable Buffers Cached SReclaimable SUnreclaim Slab Shmem AnonPages Mapped Dirty Writeback PageTables KernelStackNoch 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.logWenn der Effekt wieder auftritt, können wir beispielsweise feststellen:
MemFree -2400 MB Cached +2350 MBDann ist der Fall praktisch geklärt: Filesystem/Page Cache.
Oder:
MemFree -2400 MB Slab +2300 MBDann müssen wir uns Kernel-Caches genauer ansehen.
Oder:
MemFree -2400 MB AnonPages +2300 MBDann 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 -30Automatisch:
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.logDamit 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 slabtopsehr hilfreich.
Alternativ:
cat /proc/slabinfoEin 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
freepraktisch auf null, aberavailableü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.
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
MemFreeautomatisch 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" doneDann ausführbar machen:
sudo chmod +x /usr/local/sbin/memwatch.shZum Testen zunächst einfach im Terminal starten:
sudo /usr/local/sbin/memwatch.shDie laufenden Messwerte landen dann hier:
/var/log/memwatch/memory.logBei einem starken Einbruch entsteht zusätzlich z. B.:
/var/log/memwatch/snapshot_20260830_031023.logDarin 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.servicemit:
[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.targetDann:
sudo systemctl daemon-reload sudo systemctl enable --now memwatch.serviceStatus prüfen:
systemctl status memwatch.serviceund live ins Log schauen:
tail -f /var/log/memwatch/memory.logIch würde bei deinem Diagramm besonders auf
Cached,SReclaimable,SUnreclaim,AnonPagesundShmemachten. 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.logplus einen dersnapshot_*.loghier hochlädst, kann ich dir daraus den wahrscheinlichsten Verursacher herauslesen.Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
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 solMeine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
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
MemFreeautomatisch 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" doneDann ausführbar machen:
sudo chmod +x /usr/local/sbin/memwatch.shZum Testen zunächst einfach im Terminal starten:
sudo /usr/local/sbin/memwatch.shDie laufenden Messwerte landen dann hier:
/var/log/memwatch/memory.logBei einem starken Einbruch entsteht zusätzlich z. B.:
/var/log/memwatch/snapshot_20260830_031023.logDarin 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.servicemit:
[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.targetDann:
sudo systemctl daemon-reload sudo systemctl enable --now memwatch.serviceStatus prüfen:
systemctl status memwatch.serviceund live ins Log schauen:
tail -f /var/log/memwatch/memory.logIch würde bei deinem Diagramm besonders auf
Cached,SReclaimable,SUnreclaim,AnonPagesundShmemachten. 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.logplus einen dersnapshot_*.loghier hochlädst, kann ich dir daraus den wahrscheinlichsten Verursacher herauslesen.@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
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
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@OliverIO ich hab ja schon Probleme, wie ich das
Speichere das z. B. als /usr/local/sbin/memwatch.sh:
Speichern soll!?
sudo nano /usr/local/sbin/memwatch.shaufrufen -> leere Datei -> reinkopieren -> sichern???
Davon ab
03:10 wird das packen der history Daten beim Backup sein.Diese ist das schlechteste Beispiel, weil
Genau dieses Verhalten ist eigentlich typisch für Speicher, den Linux problemlos wiederverwenden kann.
Und iob wurde noch nie beim backup gekillt.
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 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
Hier ist ja eine Schritt für Schritt Anleitung enthalten
https://forum.iobroker.net/topic/85236/load-average-am-anschlag-neustart/107?_=1788105751660Du sollst das nicht nachbauen.
Sondern so verwendenZur 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ßenDen 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 -
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
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
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 MinutenMittlerweile 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 hab noch was editiert
-
@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 95481Weisst 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 BelastungAus 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 . . .kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
@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 95481Weisst 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 BelastungAus 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 . . .Das Script löscht Dateien alter als 14 tage
Kann man mit dem Parameter am Anfang des Skript einstellen. Keep DaysWir warten auf eine snapshot Datei
Auf wieviel hast du drop threshoud eingestelltDas Script wartet darauf das das freemen um 512mb fällt.
Wie die KI erwähnte, kannst du es auch empfindlicher einstellen mit 256 -
Das Script löscht Dateien alter als 14 tage
Kann man mit dem Parameter am Anfang des Skript einstellen. Keep DaysWir warten auf eine snapshot Datei
Auf wieviel hast du drop threshoud eingestelltDas Script wartet darauf das das freemen um 512mb fällt.
Wie die KI erwähnte, kannst du es auch empfindlicher einstellen mit 256 -
@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 95481Weisst 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 BelastungAus 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 . . .@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.Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
@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.@paul53 sehe ich genau so!
Danke -
############################################################ 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 kBEdit2
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 kBDen dazugehörigen drop hab ich gar nicht wirklich als "bedrohlich" registriert.
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
Und mal ganz doof gefragt. Kann es sein, dass der PI5 selbst eine Macke hat?
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
@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 -
Also betrifft es letztlich 2 Pi's. Schon mal einen mit Ubuntu versucht?
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
############################################################ 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 kBDa 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 kBEdit2
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 kBDen dazugehörigen drop hab ich gar nicht wirklich als "bedrohlich" registriert.
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?Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
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
-
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?@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
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
ich hab nur kopiert!
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden371
Online33.0k
Benutzende83.7k
Themen1.3m
Beiträge