Monatsrückblick Juli / August 2026 ist online!

[Homoran]

@OliverIO sagte:

Wenn dann musst du auf available mem schauen.

Jetzt kann ich es dir zeigen!

Gegen 03:00+
Available bleibt hoch, steigt sogar an, aber free geht gegen 0.

Wenn da noch etwas dazukommt schlägt der oom-reaper zu.

Noch läuft das System durch, aber ich denke wir regeln gerade nur die Symptome, die Ursache liegt irgendwo anders.

[Michael Schmitt]

@Homoran sagte:

@Michael-Schmitt
Danke, aber klonen will ich ja gar nicht. Das wäre nur bei PCIe SSD nötig.
Ich würde in dem Fall nur gerne "irgendwie easy" direkt die SSD mit raspiOS beschreiben und bootfähig haben.
Der Rest wäre dann übliche Installation und Restore

Das kannst du doch genauso mit dem pi Imager machen. Nur statt der sd die ssd als Ziel auswählen.

[Homoran]

@Michael-Schmitt sagte:

Das kannst du doch genauso mit dem pi Imager machen. Nur statt der sd die ssd als Ziel auswählen.

Danke!
Das wollte ich hören!

Homoran sagte:

Ich hab mal gesehen, dass das direkt am PC mit pi imager gehen soll, habt ihr dazu vielleicht auch einen Link?
Ich finde den Bericht nicht mehr

[Michael Schmitt]

Also alles genau wie hier super beschrieben, nur anstatt der SD dort die SSD auswählen.

installation-auf-raspi-einfacher-geht-s-nicht

[Dr. Bakterius]

@Homoran sagte:

Gegen 03:00+
Available bleibt hoch, steigt sogar an, aber free geht gegen 0.

BackItUp vielleicht? Oder was läuft sonst so um 03:00?

[Michael Schmitt]

Hast du mal ein iob diag ? Vielleicht sehen die Profis ja dort was.

[Homoran]

@Dr.-Bakterius sagte:

BackItUp vielleicht?

Möglich!
Aber der Speicher wird anscheinend nicht mehr freigegeben!
Erst 5h später

Und der memAvailable steugt nur um ca. 300-400MB während der Free um 2.5 GB zurück geht.

Aber da laufen wir wahrscheinlich in die nächste Sackgasse.
Während des backups ist iob in den letzten Tagen noch nie beendet worden.

[paul53]

@Homoran [sagte]:
Aber der Speicher wird anscheinend nicht mehr freigegeben!
Erst 5h später

Der interne Puffer des OS wird nicht gleich wieder freigegeben. Vermutlich wird eine Warteschlange aufgebaut, da die IO-Operationen nicht schnell genug erfolgen.

[Michael Schmitt]

sollte swap da nicht auch was von abfangen ? Wie sieht es da aus ?

[Homoran]

@paul53 sagte:

Vermutlich wird eine Warteschlange aufgebaut, da die IO-Operationen nicht schnell genug erfolgen.

Hmm, das klingt schon plausibel!
..undcwenn dann bei nur noch 200MB memFree noch etwas den Speicher frisst.....

Mir ging es ja auch nur um die Diskusdion mit @oliverio dass der Speicherschwund am memAvailable hätte zu sehen sein müssen, während ich es nur am memFree und dort sehr deutlich sah.

Zusätzlich war der DP system.host...freemem, den ich geloggt hatte leider auch memAvailable

[Homoran]

@Michael-Schmitt sagte:

sollte swap da nicht auch was von abfangen

WENN es in den I/O Vorgängen klemmt, dürfte da auch die Auslagerung zu spät kommen

[Homoran]

@paul53
Möglicherweise habe ich eine Denkblockade.
Wenn

Homoran sagte:

der memAvailable steigt nur um ca. 300-400MB während der Free um 2.5 GB zurück geht

würde das für mich bedeuten, dass irgendein Prozess 2000MB fest verbraucht oder reserviert.

Ersteres kann ich nirgendwo feststellen, zweiteres wüsste ich nicht wie.

Davon ab klingen plötzliche zusätzliche 2GB für einen Prozess schon sehr viel.

[paul53]

@Homoran [sagte]: zusätzliche 2GB für einen Prozess schon sehr viel.

Backitup liest und schreibt sehr viel. Da kann die Warteschlange im OS schon groß werden, wenn die I/O-Operationen ausbremsen.
Anmerkung: Ich bin kein Freund von automatischen Backups.

[Homoran]

@paul53 ich sitze zwar nicht morgens gegen 0300 vor dieser Tabelle

Aber nach der Theorie hätte dann heute morgen gegen 07:30/08:00 der mem Verbrauch von backitup deutlich höher sein müssen.

Oder geht die Speicherreservierung an iobroker vorbei?

Jetzt logge ich auch noch memHeapUsed von backitup.
Dabei reduziere ich gerade die Daten

[paul53]

@Homoran [sagte]: Oder geht die Speicherreservierung an iobroker vorbei?

Ja. Das OS hat einen eigenen Puffer. Was man mit "top" unter "buff/cache" sieht, hat nichts mit dem Speicher von ioBroker zu tun.

[Homoran]

@paul53 sagte:

Was man mit "top" unter "buff/cache

Ok, dann muss ich das mal beobachten.
Aber das wird ja nicht näher einem Prozess zugeordnet.

Die Tabelle zeigt halt alle Werte, die in top unter io.xxx gelistet sind.

Danke

[Homoran]

@paul53
Jetzt brauche ich nochmal etwas von deinem schier unendlichen Wissen 😉

Ich wollte analog zu

puh@BrokerRaspi:~ $ top | grep buff
MiB Mem :   8062.4 total,   1998.1 free,   4873.2 used,   1281.1 buff/cache
MiB Mem :   8062.4 total,   2044.9 free,   4826.4 used,   1281.1 buff/cache
MiB Mem :   8062.4 total,   2045.0 free,   4826.4 used,   1281.1 buff/cache
MiB Mem :   8062.4 total,   2049.0 free,   4822.1 used,   1281.3 buff/cache
MiB Mem :   8062.4 total,   2056.6 free,   4814.5 used,   1281.3 buff/cache
MiB Mem :   8062.4 total,   2053.1 free,   4818.0 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2057.6 free,   4813.5 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2047.4 free,   4823.7 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2053.5 free,   4817.5 used,   1281.4 buff/cache
MiB Mem :   8062.4 total,   2052.9 free,   4818.1 used,   1281.5 buff/cache
MiB Mem :   8062.4 total,   2058.3 free,   4812.8 used,   1281.5 buff/cache
MiB Mem :   8062.4 total,   2061.0 free,   4810.0 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2056.4 free,   4814.4 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2061.1 free,   4809.8 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2064.6 free,   4806.2 used,   1281.7 buff/cache
MiB Mem :   8062.4 total,   2058.2 free,   4812.6 used,   1281.7 buff/cache

eine blockly Abfrage starten.
Leider kommt kein result

Nur ein ERROR, mit dem ich nichts anfangen kann

Kannst du mir da helfen?

[paul53]

@Homoran [sagte]:
Leider kommt kein result

"top" ist kein Kommando, das sich nach Ausgabe auf stdout beendet, sondern es läuft in einem Fenster, das explizit geschlossen werden muss.
Verwende "free -m" (für kontinuierliche Ausgabe in einem Intervall ).

[Homoran]

@paul53 sagte:

Verwende "free -m" (für kontinuierliche Ausgabe in einem Intervall ).

Danke, bin ich gerade dabei.
Erstelle Liste aus result mit Trennzeichen ???
Hab es mit 5 Leerzeichen versucht und 9.lement genommen

[OliverIO]

@Homoran sagte:

@OliverIO sagte:

Wenn dann musst du auf available mem schauen.

Jetzt kann ich es dir zeigen!

Gegen 03:00+
Available bleibt hoch, steigt sogar an, aber free geht gegen 0.

Wenn da noch etwas dazukommt schlägt der oom-reaper zu.

Noch läuft das System durch, aber ich denke wir regeln gerade nur die Symptome, die Ursache liegt irgendwo anders.

Ich habe der ki mal das diagram gefüttert und hoffe die Farben richtig interpretiert zu haben
In der Antwort sind bashscripte, die direkt an der Basis aufzeichnet und nicht noch durch die ganze zeitverzögerung und zwischenverarbeitung des iobrokers verfälscht werden.

Prompt
Kannst du dir mal das diagram anschauen
Free Memory ist grün
Available mem ist orange
Rot ist was ein bestimmte Applikation (iobroker)
Benötigt.

Der starke Abfall an freiem Speicher ist nicht erklärbar. Wie könnte man rausfinden was auf einem linuxsystem das auslöst

Antwort

Ja. Das Diagramm ist sogar ziemlich interessant, weil „free“ (grün) massiv einbricht, während „available“ (orange) weitgehend stabil bleibt. Das ist unter Linux ein sehr wichtiger Unterschied.

Um ca. 03:10 Uhr passiert beispielsweise ungefähr:

• free: ~2,5 GB → fast 0
• available: bleibt bei ~3,1–3,3 GB
• ioBroker (rot): bleibt ebenfalls ungefähr gleich

Das spricht nicht unmittelbar für einen Prozess, der plötzlich 2,5 GB RAM belegt. Viel wahrscheinlicher verwendet der Linux-Kernel den vorher freien RAM für Page Cache / Buffers / Slab Cache. Dieser Speicher zählt dann nicht mehr als MemFree, kann aber bei Bedarf wieder freigegeben werden und steckt deshalb weiterhin in MemAvailable.

Als Erstes würde ich /proc/meminfo aufzeichnen

Auf dem betroffenen Rechner:

cat /proc/meminfo

Interessant sind insbesondere:

MemTotal
MemFree
MemAvailable
Buffers
Cached
SReclaimable
SUnreclaim
Slab
Shmem
AnonPages
Mapped
Dirty
Writeback
PageTables
KernelStack

Noch besser: alle 30 oder 60 Sekunden protokollieren, damit wir genau sehen, wohin die ~2,5 GB verschwinden:

while true; do
    echo "===== $(date '+%F %T') ====="
    grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|Slab|SReclaimable|SUnreclaim|Shmem|AnonPages|Mapped|Dirty|Writeback|PageTables|KernelStack' /proc/meminfo
    sleep 60
done >> /var/log/memtrace.log

Wenn der Effekt wieder auftritt, können wir beispielsweise feststellen:

MemFree       -2400 MB
Cached        +2350 MB

Dann ist der Fall praktisch geklärt: Filesystem/Page Cache.

Oder:

MemFree       -2400 MB
Slab          +2300 MB

Dann müssen wir uns Kernel-Caches genauer ansehen.

Oder:

MemFree       -2400 MB
AnonPages     +2300 MB

Dann suchen wir nach einem Prozess bzw. dessen Speicherallokationen.

Gleichzeitig die Prozesse überwachen

Ich würde zusätzlich regelmäßig die größten RAM-Verbraucher sichern:

ps -eo pid,ppid,user,rss,vsz,comm,args --sort=-rss | head -30

Automatisch:

while true; do
    echo "===== $(date '+%F %T') ====="
    ps -eo pid,ppid,user,rss,vsz,comm,args --sort=-rss | head -30
    sleep 60
done >> /var/log/procmemtrace.log

Damit sieht man hinterher z. B.:

03:09  postgres    200 MB
03:10  postgres    220 MB

→ nicht der Verursacher.

Oder:

03:09  irgendwas    50 MB
03:10  irgendwas  2400 MB

→ Volltreffer.

Falls es Slab/Kernel-Speicher ist

Dann ist

sudo slabtop

sehr hilfreich.

Alternativ:

cat /proc/slabinfo

Ein stark wachsender dentry/inode-Cache kann beispielsweise durch sehr viele Dateioperationen entstehen.

---

Ein Detail in deinem Diagramm finde ich besonders auffällig: Um ~03:10 fällt free praktisch auf null, aber available überhaupt nicht entsprechend mit. Genau dieses Verhalten ist eigentlich typisch für Speicher, den Linux problemlos wiederverwenden kann.

Deshalb würde ich zunächst keinen Memory Leak bei ioBroker vermuten. Die rote Linie unterstützt das ebenfalls: Sie macht um 03:10 keinen entsprechenden Sprung.

Wenn du möchtest, können wir das noch zielgerichteter machen: Ich kann dir ein kleines Bash-Script bauen, das alle 10 Sekunden Free/Available/Cache/Slab und die Top-20-Prozesse protokolliert und bei einem plötzlichen Free-RAM-Abfall automatisch einen detaillierten Snapshot erzeugt. Damit sollten wir den Verursacher beim nächsten Ereignis ziemlich zuverlässig erwischen.