Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Thomas Braun]

@dp20eic

Hab da länger nicht mehr reingeschaut. Der Heap ist aber sonst weiterhin bei 2GB begrenzt?

[tklein]

@dp20eic wie gesagt aktiv nur noch fhem. ich finde die speicherauslastung auch schon enorm. alles ich fast alle instanzen deaktiviert hatte, war mehr ram frei (1,2 GB genutzt). Da ging das iobroker backup auch nicht durch

[Ein ehemaliger Benutzer]

@thomas-braun sagte in Backuperstellungproblem --> JavaScript heap out of memory:

@dp20eic

Hab da länger nicht mehr reingeschaut. Der Heap ist aber sonst weiterhin bei 2GB begrenzt?

Moin,

ich bin bei Java, Node.js, usw., komplett Kompetenz befreit :), ich hangele mich da auch nur an den Fehlermeldungen durch.

VG
Bernd

[Ein ehemaliger Benutzer]

@tklein sagte in Backuperstellungproblem --> JavaScript heap out of memory:

@dp20eic wie gesagt aktiv nur noch fhem. ich finde die speicherauslastung auch schon enorm. alles ich fast alle instanzen deaktiviert hatte, war mehr ram frei (1,2 GB genutzt). Da ging das iobroker backup auch nicht durch

Moin,

ist das noch ein 32 Bit System?
Hast Du beim Backup den Speicherverbrauch auch beobachtet?

Im Zusammenhang mit dem Fehler, finde ich immer wieder den Hinweis, dass man ein Environment setzen soll, bin mir aber nicht sicher, wie und ob iobroker das dann auch nutzt.

Siehe → https://support.snyk.io/hc/en-us/articles/360002046418-JavaScript-heap-out-of-memory

VG
Bernd

[tklein]

@dp20eic ja ist ein 32 bit system.

Ich habe das bereits gemacht: https://forum.iobroker.net/topic/42792/javascript-heap-out-of-memory-workaround

[tklein]

@dp20eic said in Backuperstellungproblem --> JavaScript heap out of memory:

Hast Du beim Backup den Speicherverbrauch auch beobachtet?

ist bis 3,5 hochgegangen, dann auf 2 runter, kurz danach kam die meldung mit dem speicherproblem

[Codierknecht]

@tklein sagte in Backuperstellungproblem --> JavaScript heap out of memory:

Einfach den Ordner "vis-2-beta" rekursiv löschen? Die Views/Projekt brauch ich eh nicht

Wenn Du die Vis eh nicht brauchst, kannst Du ja (theoretisch) problemlos das Verzeichnis iobroker/node_modules/iobroker.vis löschen.
Das sollte aber eigentlich beim Deinstallieren des Adapters automatisch passieren.
Ebenso iobroker/iobroker-data/files/vis.0.
Oder wie auch immer die Verzeichnisse bei Vis2 so heißen ...

Der Objektbaum ist schon sauber?

[Homoran]

@codierknecht sagte in Backuperstellungproblem --> JavaScript heap out of memory:

Oder wie auch immer die Verzeichnisse bei Vis2 so heißen ...

die müssten natürlich überall vis2 statt vis heißen!
nicht das @tklein seine vis schreddert.

[tklein]

@homoran vis-2 habe ich manuell gelöscht. Kann man sehen, an welchen Datum ein Adapter geupdated wurde bzw ab wann er in der Adapterupdateliste stand? Evtl. macht der Back-Up Adapter dadurch Probleme bei mir. Derzeit habe ich Version v2.6.16. Werde mal zum Testen Downgraden.

[tklein]

@tklein downgrade hat auch nix gebracht.

[Homoran]

@tklein sagte in Backuperstellungproblem --> JavaScript heap out of memory:

ab wann er in der Adapterupdateliste stand?

der Adapter stand noch nie in der Updateliste.
Er ist noch im Alpha Tester Stadium und muss manuell über Github installiert werden.

[tklein]

@homoran meine frage bezog sich auf den backupadapter. hatte gehofft, dass ich am 15.03 ein updates des adapters gemacht hatte, welches das problem "verursacht"

[tklein]

Mittlerweile glaube ich, dass es nix dem dem "gobalen" Arbeitsspeicher zu tun hat:

7127	2023-04-12 15:06:27.418	error	[iobroker/clean] Backup files not deleted from /opt/iobroker/backups because some errors.
7127	2023-04-12 15:06:22.348	error	[iobroker/dropbox] Dropbox: File "/opt/iobroker/backups/iobroker_2023_04_12-15_05_43_Backup iobroker_backupiobroker.tar.gz" not found
7127	2023-04-12 15:06:14.757	error	[iobroker/iobroker] FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
7127	2023-04-12 15:06:14.755	error	[iobroker/iobroker] <--- JS stacktrace --->
7127	2023-04-12 15:06:14.754	error	[iobroker/iobroker] [5551:0x4b90e88] 31437 ms: Mark-sweep (reduce) 600.2 (615.6) -> 600.2 (604.9) MB, 261.6 / 0.0 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 2445 ms) (average mu = 0.932, current mu = 0.894) last r[5551:0x4b90e88] 31608 ms: Mark-sweep (reduce) 600.2 (604.9) -> 600.1 (604.9) MB, 170.9 / 0.0 ms (average mu = 0.889, current mu = 0.000) last resort GC in old space requested
7127	2023-04-12 15:06:14.752	error	[iobroker/iobroker] <--- Last few GCs --->

Laut RPI-Adapter war zum entsprechenen Zeitpunkt ca. 1.5 GB frei:

Evtl. ein Issue auf Github aufmachen oder kennt jemdand den Entwickler und kann ihn hier mentionen?

[Thomas Braun]

@tklein sagte in Backuperstellungproblem --> JavaScript heap out of memory:

JavaScript heap out of memory

Nein, mit dem RAM hat das auch nix zu tun sondern mit dem sog. heap.
Der ist/war bei aktuellen nodejs-Versionen auf ich glaube 2 GB begrenzt.

[tklein]

@thomas-braun ok, dann habe ich das falsh verstanden.

Jetzt habe ich das in der Console nachdem ich den Heapspeicher erhöht hatte:

pi@raspberrypi-iob:/opt/iobroker $ export NODE_OPTIONS=--max-old-space-size=8192
pi@raspberrypi-iob:/opt/iobroker $ iobroker backup
 Unable to increase LUA script timeout: Connection is closed.
 Cannot determine Set feature status: Connection is closed.
Server Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!
pi@raspberrypi-iob:/opt/iobroker $

[Thomas Braun]

@tklein

Vermutlich muss vor solchen Aktionen der iobroker gestoppt werden.