Steigender Ram/Swap nach update auf nodejs24
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.Was passiert ist: Ein Re-Pull von
latestbrachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
ohne Rebuild-Fehler.
Hab ich zwar nicht, aber warnungen, sichtbar bei Adapter Updates
Selbst prüfen: In system.host.<name> den Wert memRss mit memHeapTotal vergleichen
Muss ich mir mal ansehen, was mir generell aufgefallen ist, seit dem habe ich generell einen erhöhten RAM bzw hohe Spitzen. Warum und weshalb konnte ich aus zeitlichen Gründen noch nicht näher ausfindig machen
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.Was passiert ist: Ein Re-Pull von
latestbrachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
Kann das jemand bestätigen
Nein, kann ich nicht bestätigen. Ich fahre meine ioBroker Container seit etwa Februar mit Node 24. In den langfristigen Metriken erkennt man den Umstieg von 22>24 überhaupt nicht.
Ich bin da bei @oliverio, die Ursache scheint ein spezifischer Adapter zu sein, der bei dir das Problem in Verbindung mit Node 24 auslöst.
-
Heute war der schon kurz nach dem reboot
Ist irrelevant. Da pendelt sich ein. Beobachte das mal nach 24 Stunden.
Heute war der schon kurz nach dem reboot
Ist irrelevant. Da pendelt sich ein. Beobachte das mal nach 24 Stunden.
bin nun zum testen wieder auf nodejs24 und schau mir das mal 24 std an
-
Danke für die Werte!
@paul53: 391 MB memRss bei 129 MB Heap, also gut 260 MB außerhalb des Heaps. Das ist unauffällig. Bei mir waren es unter Node 24 1,75–2 GB bei 270–345 MB Heap, also rund 1,5 GB außerhalb.
@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.
@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.
Meine 24-h-Werte unter Node 22 kommen morgen.
-
Danke für die Werte!
@paul53: 391 MB memRss bei 129 MB Heap, also gut 260 MB außerhalb des Heaps. Das ist unauffällig. Bei mir waren es unter Node 24 1,75–2 GB bei 270–345 MB Heap, also rund 1,5 GB außerhalb.
@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.
@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.
Meine 24-h-Werte unter Node 22 kommen morgen.
@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.
das ist von jetzt, dann poste ich morgen mal das neue
-
So sieht es bei mir aus
Auf meinem Testsystem
-
@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.
das ist von jetzt, dann poste ich morgen mal das neue
Bitte aufzeichnen. Sagen wir mal bis 1h nach Neustart.
Idealerweise im Vergleich v22 und v24Die Zahlen sind Augenblicksaufnahmen.
Wie in einem anderen Thread zu einem anderen Thema gesehen,
können die Werte innerhalb von Sekunden oder sogar kürzer stark schwanken.
Das top sieht ja eigentlich entspannt aus. ist das jetzt mit v22 oder v24?
Aber halt auch nur eine AugenblicksaufnahmeWir müssen erst einmal die Ursache auf ein oder mehrere Prozesse/Adapter eingrenzen.
-
Ich kann einen Anwachs des RAM-Verbrauchs bei meinen Systemen nicht bestätigen. Ich habe in der letzten Woche alles auf nodejs 24 gehoben:
Trixie VM
Test LXC
raspberryPi Slave (4B, 8G)
-
-
Jetzt sind es nicht ganz 24 Std
@Michael-Schmitt sieht doch alles plausibel aus
-
und da ich noch drei updates einspielen mußte hier direkt nach dem reboot.
ich werd das mal so laufen lassen und beobachten
-
Danke für die Werte!
@paul53: 391 MB memRss bei 129 MB Heap, also gut 260 MB außerhalb des Heaps. Das ist unauffällig. Bei mir waren es unter Node 24 1,75–2 GB bei 270–345 MB Heap, also rund 1,5 GB außerhalb.
@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.
@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.
Meine 24-h-Werte unter Node 22 kommen morgen.
hier stand Unsinn
-
Danke für die Werte!
@paul53: 391 MB memRss bei 129 MB Heap, also gut 260 MB außerhalb des Heaps. Das ist unauffällig. Bei mir waren es unter Node 24 1,75–2 GB bei 270–345 MB Heap, also rund 1,5 GB außerhalb.
@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.
@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.
Meine 24-h-Werte unter Node 22 kommen morgen.
@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.
In der Tat hatte ich vorher eine Redis-DB im Einsatz. Habe jetzt aber mal testweise auf jsonl migriert, mit einem ähnlich entspannten Ergebnis:
-
Nachtrag nach 24 Stunden, gleiches System, gleiche Adapter, nur Node getauscht:
memRss memHeapTotal Node 24, nach ~24 h 1.749 MB 271 MB Node 22, nach ~26 h 313 MB 218 MB Unter Node 24 hat sich also nichts eingependelt.
@OliverIO: Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
Die Plattform-These nehme ich zurück: crunchips Produktivsystem (x86, 52.000 Objekte) liegt unter Node 24 ebenfalls bei rund 1,3 GB außerhalb des Heaps. Bei paul53, Marc (jsonl) und crunchips Testsystem sind es 200–300 MB, bei Michael wächst es über den Tag von rund 420 auf 640 MB. Es scheint eher mit der Größe bzw. der DB-Last zu wachsen.
@crunchip: Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
@Marc-Berg: Danke fürs Gegentesten mit jsonl!
-
keine Ahnung was mir da den Ram wegfrißt
EDIT: der js controller mit fast 40% :(
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.Was passiert ist: Ein Re-Pull von
latestbrachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0, mem_limit 4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.
Was passiert ist: Ein Re-Pull von latest brachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer
Wenn man node major updated, änder sich die ABI. Das erfordert ein npm rebuild auf die node_modules. M.W. macht das das buanet Image aber nicht eigenständig. Der js-controller hat native module die compiliert werden müssen.
-
Nachtrag nach 24 Stunden, gleiches System, gleiche Adapter, nur Node getauscht:
memRss memHeapTotal Node 24, nach ~24 h 1.749 MB 271 MB Node 22, nach ~26 h 313 MB 218 MB Unter Node 24 hat sich also nichts eingependelt.
@OliverIO: Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
Die Plattform-These nehme ich zurück: crunchips Produktivsystem (x86, 52.000 Objekte) liegt unter Node 24 ebenfalls bei rund 1,3 GB außerhalb des Heaps. Bei paul53, Marc (jsonl) und crunchips Testsystem sind es 200–300 MB, bei Michael wächst es über den Tag von rund 420 auf 640 MB. Es scheint eher mit der Größe bzw. der DB-Last zu wachsen.
@crunchip: Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
@Marc-Berg: Danke fürs Gegentesten mit jsonl!
Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
leider ist das kein indiz
der oom killer berechnet für jeden prozess einen oom score, anhand dessen entschieden wird welcher prozess beendet wird.
da der js-controller bei vielen aktivitäten mit beteiligt ist, kann auch ein adapter die ursache sein. da der js-controller prozess mehr speicher benötigt, wie ein adapter prozess, hat er einen höheren score.
in dem von mir verlinkten prozess war bspw der history adapter der verursacher, da der nutzer viele diagramme in vis eingebunden hat. der history adapter hat sehr kurzzeitig (das wäre wahrscheinlich in top gar nicht sichtbar gewesen) viele threads gestartet, die jeder für sich wieder RAM benötigt. Jeder dieser Sub-Threads haben aber nur sehr kurz gelebt.
ich will nicht sagen, das das bei dir die ursache ist, aber wie oben schon erwähnt, einmalige screenshots mit augenblickaufnahme werden wahrscheinlich nicht die ursache offenbaren.da einige über verlaufsdaten gezeigt haben, das ein wechsel von 22 auf 24 sogut wie keine auswirkungen hatte, könnte es bei dir auch etwas anderes sein.
leider ist jedes system, mit unterschiedlicher Anzahl und zusammensetzung von Adaptern sehr individuell. Wenn ein generelles Problem vorliegen würde, wären hier im Forum auch noch einige mehr threads dazu (gut die Umstellung auf v24 läuft auch erst gerade an)schau mal nochmal in den verlinkten thread rein. da sind analyse scripts drin (die leider sehr große outputs erzeugen), mit dem man tiefer analysieren könnte.
aber ich würde mal immer noch auf die aufzeichnung der memory werte von adaptern verweisen (1h dürfte reichen) idealerweise im vergleich zu v22 basis.
bspw habe ich auch diesen thread gesehen, leider ohne reaktion von irgendjemanden.
matter hatte ich glaube ich bei dir auch gesehen.
https://forum.iobroker.net/topic/85474/steigender-ram-beim-matter-adapter?_=1790863527158 -
Nachtrag nach 24 Stunden, gleiches System, gleiche Adapter, nur Node getauscht:
memRss memHeapTotal Node 24, nach ~24 h 1.749 MB 271 MB Node 22, nach ~26 h 313 MB 218 MB Unter Node 24 hat sich also nichts eingependelt.
@OliverIO: Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
Die Plattform-These nehme ich zurück: crunchips Produktivsystem (x86, 52.000 Objekte) liegt unter Node 24 ebenfalls bei rund 1,3 GB außerhalb des Heaps. Bei paul53, Marc (jsonl) und crunchips Testsystem sind es 200–300 MB, bei Michael wächst es über den Tag von rund 420 auf 640 MB. Es scheint eher mit der Größe bzw. der DB-Last zu wachsen.
@crunchip: Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
@Marc-Berg: Danke fürs Gegentesten mit jsonl!
Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
Müsst ich nachschauen.
Letztendlich läuft bei mir ein spezielles Script, der das System überwacht.
Und seit der Umstellung auf v24(aber auch ein paar Updates verschiedener Adapter) wurde ich in unregelmäßigen Abständen benachrichtigt das mein RAM überschritten ist.
Sa dann so aus
Eigentlich lag ich immer so bei 8-9Gb incl Spitzenumgestiegen von Proxmox auf Unraid
-
Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
Müsst ich nachschauen.
Letztendlich läuft bei mir ein spezielles Script, der das System überwacht.
Und seit der Umstellung auf v24(aber auch ein paar Updates verschiedener Adapter) wurde ich in unregelmäßigen Abständen benachrichtigt das mein RAM überschritten ist.
Sa dann so aus
Eigentlich lag ich immer so bei 8-9Gb incl Spitzendie veränderungen bei deinen 3 top verbrauchern ist allerdings nur sehr gering oder das gesamtsystem ist schon sehr nahe an deinen 10gb
größere veränderungen bei anderen adaptern die dann zum überschwappen führen sieht man da nicht.Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
Hm, ich muss das mal eine längere Zeitspanne beobachten.
Hier meine Werte der letzen 30 Tage. Am 27.09. habe ich die Proxmox VM (8G) und den Raspberrypi (Version B, 8G) auf nodejs 24 gebracht.
Es hat sich tatsächlich etwas getan, aber als dramatisch würde ich es nicht bezeichnen.
VM
RPI
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 Anmelden481
Online33.1k
Benutzende83.9k
Themen1.4m
Beiträge