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

[tklein]

@thomas-braun inzwischen habe ich die instanzen wieder gestartet. 2 versuche haben ja nix anders gebracht

[tklein]

@thomas-braun jetzt sind es nur noch 4

[Thomas Braun]

@tklein Das hört sich vernünftiger an.

[Thomas Braun]

@tklein

Welche Größe hatte die Backups eigentlich in der Vergangenheit?
Und hast du seit die nicht mehr funktionieren irgendwelche Daten-Dickschiff-Adapter installiert? Überwachungskameras oder sonst was mit reichlich Datenerzeugung?

[tklein]

@thomas-braun leider wieder keine änderung:

pi@raspberrypi-iob:/opt/iobroker $ iobroker stop
pi@raspberrypi-iob:/opt/iobroker $ iobroker backup
host.raspberrypi-iob 33899 states saved
host.raspberrypi-iob 39808 objects saved

<--- Last few GCs --->

[9086:0x4b25cd0]    37366 ms: Scavenge 887.2 (969.0) -> 887.1 (974.0) MB, 9.7 / 0.0 ms  (average mu = 0.919, current mu = 0.812) allocation failure
[9086:0x4b25cd0]    37394 ms: Scavenge 890.0 (974.0) -> 889.9 (975.0) MB, 14.2 / 0.0 ms  (average mu = 0.919, current mu = 0.812) allocation failure
[9086:0x4b25cd0]    37548 ms: Scavenge 890.9 (975.0) -> 890.6 (986.0) MB, 149.5 / 0.0 ms  (average mu = 0.919, current mu = 0.812) allocation failure


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
/usr/bin/iobroker: line 10:  9085 Aborted                 sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js "$@"
pi@raspberrypi-iob:/opt/iobroker $

[tklein]

@thomas-braun ich habe bißcehn mit einer vis rumgespielt und den ring adapter wieder reaktiviert

[Thomas Braun]

@tklein

Die Daten aus dem ring-Adapter könnten der Grund sein.

[tklein]

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

Welche Größe hatte die Backups eigentlich in der Vergangenheit?

iobroker ca 20 mb / db 160-200 mb

[tklein]

@thomas-braun

pi@raspberrypi-iob:/ $ tree -d -h -L 1 /opt/iobroker/iobroker-data/ring*
/opt/iobroker/iobroker-data/ring.0
/opt/iobroker/iobroker-data/ring_0
└── [ 20K]  snapshot

1 directory
pi@raspberrypi-iob:/ $ tree -d -h -L 1 /opt/iobroker/iobroker-data/ring.0
/opt/iobroker/iobroker-data/ring.0

0 directories
pi@raspberrypi-iob:/ $ tree -d -h -L 1 /opt/iobroker/iobroker-data/ring_0
/opt/iobroker/iobroker-data/ring_0
└── [ 20K]  snapshot

1 directory
pi@raspberrypi-iob:/ $ tree -d -h -L 1 /opt/iobroker/iobroker-data/files/rin*
/opt/iobroker/iobroker-data/files/ring.0
├── [4.0K]  stickup_127478700
└── [ 76K]  stickup_52891477
/opt/iobroker/iobroker-data/files/ring.admin
└── [ 68K]  snapshot

3 directories

[tklein]

die ist schon ganz ordentlich wie ich finde:

[DJMarc75]

@tklein das ist auch quasi ALPHA und erklärt "jetzt" einiges...

[Codierknecht]

@tklein
Damit dürfte die Ursache klar sein.
Hättest ja auch gleich schreiben können, dass Du mit der Vis 2 rumspielst. Die ist noch im Alpha-Stadium - also nur zum Testen.

Beim Backup muss der ganze Salat auch noch gepackt werden - und das braucht vor allem eins: RAM RAM RAM.

[tklein]

@djmarc75 adapter gelöscht, daten noch da...

[tklein]

@codierknecht sorry, hatte so nicht an den zusammenhang gedacht. wie kann ich am besten die daten löschen, die nach dem adapterdelete noch da sind?

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

[DJMarc75]

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

wie kann ich am besten die daten löschen, die nach dem adapterdelete noch da sind

Prinzipiell mit den eigenen Kenntnissen entscheiden ob man Beta- (und alpha mal ganz weg gelassen) Tester spielen mag ! Kein Vorwurf sondern ein Denkanstoss !
Wie man da jetzt vom VIS2 alles terminiert - keine Ahnung.

[tklein]

daran lag es leider auch/doch nicht. files sind gelöscht:

[DEBUG] [iobroker] - host.raspberrypi-iob 39787 objects saved

[ERROR] [iobroker] - 
<--- Last few GCs --->

[1372:0x49cfe88]    30372 ms: Mark-sweep (reduce) 600.1 (616.2) -> 600.0 (605.0) MB, 249.0 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 2931 ms) (average mu = 0.934, current mu = 0.916) last r[1372:0x49cfe88]    30500 ms: Mark-sweep (reduce) 600.0 (605.0) -> 600.0 (604.7) MB, 128.2 / 0.0 ms  (average mu = 0.903, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[Ein ehemaliger Benutzer]

@tklein

Moin,

ich habe mich gerade etwas in node.js eingelesen und da steht, dass node.js > V12 den freien Speicher des Systems nutzt für den Heap, wenn Du wie oben gezeigt hast, nur 300 MB freihast, kann es sein, dass Du damit nicht ans Ziel kommst. Hast Du mal, während Du das Backup anstößt, parallel geschaut, wie es mit dem Speicherverbrauch zur selben Zeit aussieht.
Läuft da noch anderer Kram drauf? Versuch mal so viel wie möglich auf der Kiste zu stoppen, um freien Speicher zu bekommen.

VG
Bernd

[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