Monatsrückblick Oktober 2026 ist online!

[Michael Schmitt]

Hi, hab nun mal ein javascript schreiben lassen, was mir die Werte aufzeichnet.

1.10.2026 20:50:07;Node=24.21.0;RSS=791.9MB;HeapUsed=142.55MB;HeapTotal=152.27MB;MemAvail=705MB;Mem%=82
1.10.2026 21:00:00;Node=24.21.0;RSS=792.4MB;HeapUsed=142.32MB;HeapTotal=154.34MB;MemAvail=766MB;Mem%=81
1.10.2026 21:30:00;Node=24.21.0;RSS=728.76MB;HeapUsed=138.84MB;HeapTotal=151.39MB;MemAvail=858MB;Mem%=78
1.10.2026 22:00:00;Node=24.21.0;RSS=730.2MB;HeapUsed=142.13MB;HeapTotal=152.09MB;MemAvail=829MB;Mem%=79
1.10.2026 22:30:00;Node=24.21.0;RSS=735.24MB;HeapUsed=141.24MB;HeapTotal=153.39MB;MemAvail=946MB;Mem%=76
1.10.2026 23:00:00;Node=24.21.0;RSS=723.14MB;HeapUsed=141.21MB;HeapTotal=153.04MB;MemAvail=896MB;Mem%=77
1.10.2026 23:30:00;Node=24.21.0;RSS=733.27MB;HeapUsed=145.16MB;HeapTotal=154.39MB;MemAvail=890MB;Mem%=78
1.10.2026 23:41:09;Node=24.21.0;RSS=752.94MB;HeapUsed=154.67MB;HeapTotal=208.59MB;MemAvail=842MB;Mem%=79
2.10.2026 00:00:00;Node=24.21.0;RSS=723.12MB;HeapUsed=142.58MB;HeapTotal=152.1MB;MemAvail=891MB;Mem%=78
2.10.2026 00:30:00;Node=24.21.0;RSS=730.03MB;HeapUsed=141.06MB;HeapTotal=154.7MB;MemAvail=858MB;Mem%=78
2.10.2026 01:00:00;Node=24.21.0;RSS=737.15MB;HeapUsed=145.48MB;HeapTotal=152.37MB;MemAvail=869MB;Mem%=78
2.10.2026 01:30:00;Node=24.21.0;RSS=745.77MB;HeapUsed=147.16MB;HeapTotal=178.8MB;MemAvail=884MB;Mem%=78
2.10.2026 02:00:00;Node=24.21.0;RSS=831.37MB;HeapUsed=194.1MB;HeapTotal=275.73MB;MemAvail=763MB;Mem%=81
2.10.2026 02:30:00;Node=24.21.0;RSS=752.71MB;HeapUsed=141.73MB;HeapTotal=151.05MB;MemAvail=866MB;Mem%=78
2.10.2026 03:00:00;Node=24.21.0;RSS=724.37MB;HeapUsed=143.07MB;HeapTotal=154.64MB;MemAvail=867MB;Mem%=78
2.10.2026 03:30:00;Node=24.21.0;RSS=737.82MB;HeapUsed=143.14MB;HeapTotal=149.56MB;MemAvail=835MB;Mem%=79
2.10.2026 04:00:00;Node=24.21.0;RSS=727.24MB;HeapUsed=139.55MB;HeapTotal=145.39MB;MemAvail=818MB;Mem%=79
2.10.2026 04:30:00;Node=24.21.0;RSS=730.53MB;HeapUsed=145.72MB;HeapTotal=151.17MB;MemAvail=849MB;Mem%=79
2.10.2026 05:00:00;Node=24.21.0;RSS=722.84MB;HeapUsed=144.9MB;HeapTotal=152.48MB;MemAvail=832MB;Mem%=79
2.10.2026 05:30:00;Node=24.21.0;RSS=732.61MB;HeapUsed=143.88MB;HeapTotal=148.14MB;MemAvail=818MB;Mem%=79
2.10.2026 06:00:00;Node=24.21.0;RSS=730.51MB;HeapUsed=139.77MB;HeapTotal=154.05MB;MemAvail=841MB;Mem%=79
2.10.2026 06:30:00;Node=24.21.0;RSS=722.63MB;HeapUsed=143.9MB;HeapTotal=152.82MB;MemAvail=835MB;Mem%=79
2.10.2026 07:00:00;Node=24.21.0;RSS=729.11MB;HeapUsed=141.64MB;HeapTotal=150.04MB;MemAvail=839MB;Mem%=79
2.10.2026 07:30:00;Node=24.21.0;RSS=736.28MB;HeapUsed=142.95MB;HeapTotal=149.89MB;MemAvail=818MB;Mem%=79
2.10.2026 08:00:00;Node=24.21.0;RSS=735.44MB;HeapUsed=142.05MB;HeapTotal=153.54MB;MemAvail=803MB;Mem%=80
2.10.2026 08:30:00;Node=24.21.0;RSS=734.91MB;HeapUsed=141.51MB;HeapTotal=148.95MB;MemAvail=803MB;Mem%=80
2.10.2026 09:00:00;Node=24.21.0;RSS=721.85MB;HeapUsed=141.05MB;HeapTotal=150.86MB;MemAvail=846MB;Mem%=79
2.10.2026 09:30:00;Node=24.21.0;RSS=730.73MB;HeapUsed=144.47MB;HeapTotal=152.27MB;MemAvail=832MB;Mem%=79
2.10.2026 10:00:00;Node=24.21.0;RSS=732.49MB;HeapUsed=141.79MB;HeapTotal=154.93MB;MemAvail=806MB;Mem%=80
2.10.2026 10:30:00;Node=24.21.0;RSS=896.13MB;HeapUsed=149.12MB;HeapTotal=272.88MB;MemAvail=625MB;Mem%=84
2.10.2026 11:00:00;Node=24.21.0;RSS=875.22MB;HeapUsed=145.17MB;HeapTotal=155.52MB;MemAvail=677MB;Mem%=83
2.10.2026 11:30:00;Node=24.21.0;RSS=744.49MB;HeapUsed=145.48MB;HeapTotal=152.14MB;MemAvail=781MB;Mem%=80
2.10.2026 12:00:00;Node=24.21.0;RSS=757.24MB;HeapUsed=144.07MB;HeapTotal=154.34MB;MemAvail=768MB;Mem%=81
2.10.2026 12:30:00;Node=24.21.0;RSS=774.14MB;HeapUsed=144.11MB;HeapTotal=162.55MB;MemAvail=787MB;Mem%=80
2.10.2026 13:00:00;Node=24.21.0;RSS=765.51MB;HeapUsed=142.85MB;HeapTotal=151.32MB;MemAvail=765MB;Mem%=81

dann kam das normale repository update

admin.0 	2026-10-02 13:21:49.140	info	Repository received successfully.
host.Raspberry	2026-10-02 13:21:27.169	info	Updating repository "stable" under "http://download.iobroker.net/sources-dist.json"
admin.0		2026-10-02 13:21:25.774	info	Request actual repository...

und dann ging es so weiter

2.10.2026 13:30:00;Node=24.21.0;RSS=998.18MB;HeapUsed=143.34MB;HeapTotal=146.93MB;MemAvail=730MB;Mem%=82
2.10.2026 13:43:00;Node=24.21.0;RSS=1159.45MB;HeapUsed=149.15MB;HeapTotal=208.55MB;MemAvail=416MB;Mem%=90
2.10.2026 13:50:00;Node=24.21.0;RSS=1018.55MB;HeapUsed=144.81MB;HeapTotal=152.34MB;MemAvail=570MB;Mem%=86
2.10.2026 14:00:00;Node=24.21.0;RSS=1024.71MB;HeapUsed=143.33MB;HeapTotal=150.27MB;MemAvail=509MB;Mem%=87
2.10.2026 14:10:00;Node=24.21.0;RSS=1028.86MB;HeapUsed=147.14MB;HeapTotal=154.01MB;MemAvail=489MB;Mem%=88
2.10.2026 14:20:00;Node=24.21.0;RSS=1027.05MB;HeapUsed=145.43MB;HeapTotal=160.46MB;MemAvail=492MB;Mem%=88
2.10.2026 14:30:00;Node=24.21.0;RSS=1022.54MB;HeapUsed=141.1MB;HeapTotal=148.8MB;MemAvail=538MB;Mem%=86
2.10.2026 14:40:00;Node=24.21.0;RSS=1028.2MB;HeapUsed=142.64MB;HeapTotal=155.54MB;MemAvail=528MB;Mem%=87
2.10.2026 14:50:00;Node=24.21.0;RSS=1028.37MB;HeapUsed=146.78MB;HeapTotal=163.39MB;MemAvail=528MB;Mem%=87
2.10.2026 15:00:00;Node=24.21.0;RSS=1028.23MB;HeapUsed=146.81MB;HeapTotal=153.39MB;MemAvail=525MB;Mem%=87
2.10.2026 15:10:00;Node=24.21.0;RSS=1029.37MB;HeapUsed=142.57MB;HeapTotal=149.64MB;MemAvail=496MB;Mem%=88
2.10.2026 15:20:00;Node=24.21.0;RSS=1029.36MB;HeapUsed=143.58MB;HeapTotal=151.39MB;MemAvail=508MB;Mem%=87

mal schauen ob sich das wieder fängt

EDIT: für mich schaut es so aus als wenn der Ram nichtmehr freigegeben wird. Normal war wenn swap hoch geht dann steigt wieder Ram free und available

[rscsb]

@obstbauer sagte:

Neuer Raspi bei den Preisen ist natürlich erstmal eher nicht die erste Option :)

Deshalb habe ich ja "mittelfristig" geschrieben - das gilt ja bis zu 5 Jahren ;-)

Wie kann ich schauen, ob ich den Pi überlade, wenn ich auf v24 Wechsel ?

Ich dachte das hast Du schon installiert gehabt. Bis dann nichts mehr ging.
Das mache ich mit "top" im Konsolenfenster - dort der Bereich Mib Spch/Mib Swap
Kann aber nicht mehr genau sagen, ob die SWAP-Spalte im Standard ist, oder ob ich
die mal hingepfriemelt habe. Hier ist dann erkennbar welche Programmteile im SWAP liegen.

Zusätzlich lasse ich mir in der VIS über den Adapter linux-control noch folgendes anzeigen:

[fritzke316]

Ich habe das selbe bemerkt seit dem Update auf Admin 8 und nodejs 24 braucht mein Pi4 8GB viel mehr RAM vorher ca. 50% nun nach etwas Laufzeit 80% und mehr.
Nach einem Neustart sind es 54%

[Thomas Braun]

nodejs 24 verwendet vorhandene Speicher jetzt einfach effizienter und ist dadurch schneller.
Eine Auslastung von 80% ist auch erstmal per se nicht kritisch.
Dazu stellt man auch am besten eine ausreichend großes SWAP zur Verfügung. Neue Grundinstallationen von z. B. RaspberryOS tun das seit einiger Zeit von Haus aus. Auf meinem 8GB Pi4 wurden unlängst direkt 2GB als SWAP eingerichtet.

Auf weitere unnötige Speicherfresser wie einen Desktop verzichtet man ja ohnehin (aus diversen Gründen).
So lange der ioBroker nicht vom OutOfMemory-Daemon gekillt wird sehe ich da keinen Grund für Sorgen.

[fritzke316]

Ich war jetzt nicht direkt in Sorge, wollte nur darauf hinweisen.
Mein System läuft soweit gut und solange der Speicher reicht ist alles gut :)

[Michael Schmitt]

@Thomas-Braun sagte:

nodejs 24 verwendet vorhandene Speicher jetzt einfach effizienter und ist dadurch schneller.
Eine Auslastung von 80% ist auch erstmal per se nicht kritisch.
Dazu stellt man auch am besten eine ausreichend großes SWAP zur Verfügung. Neue Grundinstallationen von z. B. RaspberryOS tun das seit einiger Zeit von Haus aus. Auf meinem 8GB Pi4 wurden unlängst direkt 2GB als SWAP eingerichtet.

Auf weitere unnötige Speicherfresser wie einen Desktop verzichtet man ja ohnehin (aus diversen Gründen).
So lange der ioBroker nicht vom OutOfMemory-Daemon gekillt wird sehe ich da keinen Grund für Sorgen.

und mein Raspi4 4gb der muß dann weg ? Ich hatte noch 200mb free Ram und 500mb available

[Thomas Braun]

@Michael-Schmitt sagte:

und mein Raspi4 4gb der muß dann weg ?

Das hängt sehr von deiner individuellen Situation ab. Grundsätzlich ist das ja kein Problem, sind ja noch 500MB verfügbar. Die Angabe von 'free' ist ja auch eher uninteressant. Du fährst dein Auto ja auch nicht halb in die Garage, damit dann zwischen Wand und Stoßstange was 'free' bleibt.

[Michael Schmitt]

von 24 wieder auf 22 und das ist der Unterschied

2.10.2026 15:40:00;Node=24.21.0;RSS=1023.64MB;HeapUsed=144.23MB;HeapTotal=152.14MB;MemAvail=512MB;Mem%=87
2.10.2026 15:50:00;Node=24.21.0;RSS=1157.29MB;HeapUsed=145.58MB;HeapTotal=154.64MB;MemAvail=354MB;Mem%=91
2.10.2026 15:52:50;Node=22.23.3;RSS=483.38MB;HeapUsed=216.9MB;HeapTotal=243.74MB;MemAvail=1849MB;Mem%=54
2.10.2026 15:58:57;Node=22.23.3;RSS=560.63MB;HeapUsed=260.97MB;HeapTotal=304.48MB;MemAvail=1826MB;Mem%=54
2.10.2026 16:00:00;Node=22.23.3;RSS=549.11MB;HeapUsed=187.82MB;HeapTotal=218.71MB;MemAvail=892MB;Mem%=78
2.10.2026 16:10:00;Node=22.23.3;RSS=401.5MB;HeapUsed=145.98MB;HeapTotal=186.21MB;MemAvail=1288MB;Mem%=68
2.10.2026 16:20:00;Node=22.23.3;RSS=406.07MB;HeapUsed=139.66MB;HeapTotal=161.64MB;MemAvail=1259MB;Mem%=68
2.10.2026 16:30:00;Node=22.23.3;RSS=398.19MB;HeapUsed=143.67MB;HeapTotal=150.38MB;MemAvail=1200MB;Mem%=70

[Thomas Braun]

@Michael-Schmitt sagte:

von 24 wieder auf 22 und das ist der Unterschied

Was ist denn KONKRET dein Problem? Werden Prozesse gekillt? Funktioniert dein automatisches Backup nachts nicht mehr?

[crunchip]

@Thomas-Braun naja, aber was ist dann effizient?
Das Auto steht zur Hälfte im Regen, weil ja vorn "free", dafür bau ich mir vor die Garage noch ne Überdachung, damit`s Auto nicht nass wird.

[Michael Schmitt]

Deswegen hab ich ne Garage wo zwei Autos hintereinander rein gehen und noch Fahrräder davor So Bespiele liebe ich.

Mein Problem ist das mein kleines System ohne mein zutun immer weiter aufgeblasen wird und ich über kurz oder lang Geld ausgeben muß um das am laufen zu halten.

[Thomas Braun]

@crunchip sagte:

naja, aber was ist dann effizient?

Effizient wäre es, den vorhandenen RA(u)M zu verwenden und nicht brach liegen zu lassen.

[crunchip]

@Thomas-Braun der vorhandene sind ja die 4GB echten , sobald kontinuierlich Swap in Anspruch genommen wird, sehe ich das nicht als effizient an

[Thomas Braun]

@crunchip

Das überlasse ich dem Memory-Management des Kernels. Der weiß i. d. R. wo gewisse Daten momentan am besten aufgehoben sind.

[crunchip]

@Thomas-Braun was man im Bedarfsfall aber auch optimieren könnte

[OliverIO]

@Michael-Schmitt

das ist leider der lauf der Aktualität.
du kannst ja mal probieren windows 11 auf einen rechner zu installieren wo win95 lief.
ob diese entwicklung gut ist? die einen sprechen von geplanter obsolezenz, die anderen von Sicherheit und mehr Anforderungen.

[rscsb]

@crunchip sagte:

der vorhandene sind ja die 4GB echten , sobald kontinuierlich Swap in Anspruch genommen wird, sehe ich das nicht als effizient an

Das sollte man nicht so getrennt sehen. Sogar bei Systemen die mehrere zehn- oder hunderttausend Euro kosten wird das bei der Konfiguration als "Arbeitsspeicher" geplant. Der besteht dann aus schnellem Speicher (RAM) und langsamerem (SWAP).

Aber ja, man kann sich damit auch Nachteile erschaffen. Mehr Datenverkehr auf dem Bus - mehr Zugriffe auf Platte oder SSD. SD-Karte ist natürlich dann fast ein no-go.
Aber verteufeln sollte man diese "Technik" nicht.

[Thomas Braun]

Mein Hauptsystem schaut momentan so aus:

echad@chet:~ $ free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:      7,6Gi       6,2Gi       640Mi       238Mi       1,1Gi       1,4Gi
Swap:          2,0Gi       533Mi       1,5Gi
echad@chet:~ $

Und das macht mir gerade gar keine Kopfschmerzen. Gut, die Basis ist da mit 8GB auch erstmal für 'Stand heute' groß genug. Irgendwann wird da aber auch mal ein Hardware-Upgrade fällig werden. Aber das ist ja überall so. Eine ausreichende Ausstattung von vor einigen Jahren reicht heute auch nicht mehr aus. Wie viele eigentlich gut ausgestatte Computer sind z. B. nicht mehr mit Windows 11 kompatibel?

Edit: Die KI bekommt da auch keine Kopfschmerzen, zumal SWAP ja als ZRAM angelegt ist und daher das Speichermedium nicht physisch belastet:

Aktueller Zustand
• Arbeitsspeicher (RAM): Das System verfügt über 8 GB Gesamtspeicher (7,6 GiB netto). Davon sind aktuell rund 80 % ausgelastet (6,2 GiB benutzt). Es verbleibt eine absolut ausreichende Reserve von 1,4 GiB verfügbarem Speicher für Lastspitzen.
• Auslagerungsspeicher (Swap): Es sind 2,0 GiB Swap eingerichtet, wovon derzeit 533,8 MiB (ca. 25 %) aktiv genutzt werden.
Besonderheit & Hardware-Schonung
• Reines ZRAM-Setup: Die Überprüfung hat gezeigt, dass der Swap exklusiv als zram0 im Arbeitsspeicher läuft.
• Keine SSD-Belastung: Daten werden nicht physisch auf die verbaute Transcend-SSD geschrieben, sondern hochkomprimiert im RAM abgelegt. Dies verhindert jeglichen SSD-Verschleiß durch Auslagerungsprozesse.
• Optimale Performance: Durch die Auslagerung in den komprimierten RAM bleibt das System trotz der hohen RAM-Auslastung extrem schnell und effizient.
Gesamtfazit: Das System läuft unter spürbarer, aber völlig gesunder Last.

Es ist optimal konfiguriert, nutzt die Hardware perfekt aus und erfordert aktuell keinerlei administrativen Handlungsbedarf.

[Thomas Braun]

Ich hab gerade mal nach Benchmarks geschaut. Hier

https://medium.com/@quicksilversel/i-upgraded-from-node-20-to-24-and-cpu-usage-dropped-i-didnt-change-any-code-d9c2cadcda85

wird z. B. gesagt:

The Memory Number That Almost Worried Me

Here’s something I noticed mid-investigation that nearly sent me down a wrong path: heap_size_limit went up after the upgrade.

My first reaction was “uh oh.” Higher heap ceiling sounds like the app is reaching for more memory. Is something leaking?

No. It’s actually a good sign.

Newer V8 versions (around Node 22+) include heuristics that set the default New Space size dynamically based on available system memory, instead of using static defaults. V8 is now giving itself a larger ceiling to work with.

Here’s why that’s good:

A larger buffer for newly allocated objects gives the rapid Scavenge collector more time to identify and reclaim short-lived garbage before the allocation space fills up. That reduces premature promotion to Old Space. Which reduces the frequency of slow, disruptive Old Space (major) GC cycles.

In other words:

Higher heap_size_limit → fewer major GC cycles → less CPU usage and lower event loop delays.

The runtime is trading a little memory headroom for dramatically less GC pressure. In production, RAM is almost always more abundant than CPU cycles. It’s the right trade.

[FernetMenta]

@michael-schmitt magst du mal dein Javescript posten, das dir die Werte ausgibt? Vielleicht könnten das ja mal paar Leute hier auch laufen lassen. Dann kann man das vergleichen.