Steigender Ram/Swap nach update auf nodejs24
-
Hi,
ich weiss nicht ob und mit was das zusammen hängt, aber mir kommt es so vor das mein Raspi immer mehr Ram braucht. System ist aktuell mit nodejs24 und Admin 8.0.20.
Früher war der Ram nach einem reboot so bei ca 65% jetzt bei 85% und der swap hat sich früher so ab dem zweiten tag langsam gefüllt. Heute war der schon kurz nach dem reboot bei über 900mb (mittlerweile auf ca 600 gefallen)Mein System ist echt klein und ich hab alles unnützen an Adaptern deinstalliert. Klar der Raspi 4 mit 4gb ist kein Rechenmonster, aber er hat sonst immer gute Dienste geleistet und Hardware ist leider sehr teuer geworden.
Was kann das sein, dass mein System so in die Knie geht ?
Script v.2026-08-30 *** BASE SYSTEM *** Operating System: Debian GNU/Linux 13 (trixie) Static hostname: Raspberry Icon name: computer Kernel: Linux 6.18.50+rpt-rpi-v8 Architecture: arm64 OS is similar to: Model : Raspberry Pi 4 Model B Rev 1.2 Docker : false Virtualization : none Unknown Kernel : aarch64 Userland : 64bit System was installed 169 days ago (on 2026-04-13). Systemuptime and Load: 00:05:56 up 35 min, 1 user, load average: 0.95, 0.54, 0.62 CPU threads : 4 *** LIFE CYCLE STATUS *** Operating System is the current Debian stable version codenamed 'trixie'! *** RASPBERRY THROTTLING *** Current issues: No throttling issues detected. Previously detected issues: No throttling issues detected. *** TIME AND TIMEZONES *** Local time: Wed 2026-09-30 00:05:56 CEST Universal time: Tue 2026-09-29 22:05:56 UTC RTC time: n/a Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no *** Users and Groups *** User that called 'iob diag': marvman67 HOME=/home/marvman67 GROUPS=marvman67 adm dialout cdrom sudo audio video plugdev games users netdev gpio i2c spi render input iobroker User that is running 'js-controller': iobroker HOME=/home/iobroker GROUPS=iobroker tty dialout audio video plugdev bluetooth gpio i2c *** DISPLAY-SERVER SETUP *** Display-Server: Unknown Display-Manager: Not found Desktop: Session: tty Boot Target: multi-user.target *** MEMORY *** total used free shared buff/cache available Mem: 4.0G 3.3G 288M 3.1M 475M 689M Swap: 2.1G 939M 1.2G Total: 6.1G 4.2G 1.5G Active iob-Instances: 19 3794 M total memory 3137 M used memory 1518 M active memory 1429 M inactive memory 275 M free memory 28 M buffer memory 425 M swap cache 2047 M total swap 895 M used swap 1152 M free swap *** top - Table Of Processes *** top - 00:05:56 up 35 min, 1 user, load average: 0.95, 0.54, 0.62 Tasks: 184 total, 1 running, 183 sleeping, 0 stopped, 0 zombie %Cpu(s): 9.8 us, 2.0 sy, 0.0 ni, 84.3 id, 3.9 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3794.7 total, 274.0 free, 3137.6 used, 454.4 buff/cache MiB Swap: 2048.0 total, 1152.1 free, 895.9 used. 657.2 avail Mem *** FAILED SERVICES *** UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. *** DMESG CRITICAL ERRORS *** No critical errors detected *** FILESYSTEM *** Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 1.6G 0 1.6G 0% /dev tmpfs tmpfs 759M 9.0M 750M 2% /run /dev/sda2 ext4 229G 8.2G 212G 4% / tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs tmpfs 5.0M 16K 5.0M 1% /run/lock tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service tmpfs tmpfs 1.9G 2.9M 1.9G 1% /tmp /dev/sda1 vfat 505M 67M 439M 14% /boot/firmware tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/serial-getty@ttyS0.service tmpfs tmpfs 380M 12K 380M 1% /run/user/1000 Messages concerning filesystems in dmesg (Last 15 lines only): [Tue Sep 29 23:30:13 2026] EXT4-fs (sda2): orphan cleanup on readonly fs [Tue Sep 29 23:30:14 2026] EXT4-fs (sda2): mounted filesystem 687fa5d6-7e12-409f-8631-6b47ecc831af ro with ordered data mode. Quota mode: none. [Tue Sep 29 23:30:17 2026] EXT4-fs (sda2): re-mounted 687fa5d6-7e12-409f-8631-6b47ecc831af r/w. Show mounted filesystems: TARGET SOURCE FSTYPE OPTIONS / /dev/sda2 ext4 rw,noatime `-/boot/firmware /dev/sda1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro Files in neuralgic directories: /var: 2.5G /var/ 305M /var/cache 299M /var/cache/apt 190M /var/lib 167M /var/cache/apt/archives Archived and active journals take up 8M in the file system. /opt/iobroker/backups: 379M /opt/iobroker/backups/ /opt/iobroker/iobroker-data: 348M /opt/iobroker/iobroker-data/ 162M /opt/iobroker/iobroker-data/files 140M /opt/iobroker/iobroker-data/backup-objects 29M /opt/iobroker/iobroker-data/files/javascript.admin 17M /opt/iobroker/iobroker-data/files/iqontrol The five largest files in iobroker-data are: 39M /opt/iobroker/iobroker-data/objects.jsonl 16M /opt/iobroker/iobroker-data/files/matter.admin/assets/index-EdnNzxJx.js 9.2M /opt/iobroker/iobroker-data/files/devices/assets/index-B5AVJug5.js 9.0M /opt/iobroker/iobroker-data/files/devices.admin/assets/index-C7m-AE0T.js 7.5M /opt/iobroker/iobroker-data/states.jsonl USB-Devices by-id: USB-Sticks - Avoid direct links to /dev/tty* in your adapter setups, please always prefer the links 'by-id': /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2706986-if00 No nvbackup.json found. *** NodeJS-Installation *** /usr/bin/nodejs v24.21.0 /usr/bin/node v24.21.0 /usr/bin/npm 11.19.0 /usr/bin/npx 11.19.0 ✓ Node.js installation is correct nodejs: Installed: 24.21.0-1nodesource1 Candidate: 24.21.0-1nodesource1 Version table: *** 24.21.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 100 /var/lib/dpkg/status 24.20.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.19.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.18.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.18.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.17.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.16.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.15.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.14.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.14.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.13.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.13.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.12.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.11.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.11.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.10.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.9.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.8.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.7.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.6.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.5.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.4.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.4.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.3.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.1.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.0.2-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.0.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 24.0.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main arm64 Packages 20.19.2+dfsg-1+deb13u2 500 500 http://deb.debian.org/debian trixie/main arm64 Packages 500 http://deb.debian.org/debian-security trixie-security/main arm64 Packages Temp directories causing deletion problem: 0 No problems detected Errors in npm tree: 0 No problems detected Checking for nodejs vulnerability: No known Vulnerabilities detected! *** ioBroker-Installation *** ioBroker Status iobroker is running on this host. Objects type: jsonl States type: jsonl Hosts: Raspberry Raspberry (version: 7.2.2, hostname: Raspberry , alive, uptime: 2141) Core adapters versions js-controller: 7.2.2 admin: 8.0.20 javascript: 10.2.4 nodejs modules from github: 0 Adapter State + system.adapter.admin.0 : admin : Raspberry - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.alexa2.0 : alexa2 : Raspberry - enabled + system.adapter.backitup.0 : backitup : Raspberry - enabled + system.adapter.deconz.0 : deconz : Raspberry - enabled, port: 80 + system.adapter.devices.0 : devices : Raspberry - enabled + system.adapter.email.0 : email : Raspberry - enabled + system.adapter.fritzdect.0 : fritzdect : Raspberry - enabled system.adapter.ical.0 : ical : Raspberry - enabled + system.adapter.iqontrol.0 : iqontrol : Raspberry - enabled + system.adapter.javascript.0 : javascript : Raspberry - enabled + system.adapter.linux-control.0 : linux-control : Raspberry - enabled + system.adapter.matter.0 : matter : Raspberry - enabled + system.adapter.ping.0 : ping : Raspberry - enabled + system.adapter.rpi2.0 : rpi2 : Raspberry - enabled + system.adapter.simple-api.0 : simple-api : Raspberry - enabled, port: 8087, bind: 0.0.0.0, run as: admin + system.adapter.socketio.0 : socketio : Raspberry - enabled, port: 8084, bind: 192.168.178.42, run as: admin + system.adapter.telegram.0 : telegram : Raspberry - enabled, port: 8443, bind: 0.0.0.0 + system.adapter.trashschedule.0 : trashschedule : Raspberry - enabled + system.adapter.web.0 : web : Raspberry - enabled, port: 8082, bind: 0.0.0.0, run as: admin + instance is alive Enabled adapters with bindings + system.adapter.admin.0 : admin : Raspberry - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.deconz.0 : deconz : Raspberry - enabled, port: 80 + system.adapter.simple-api.0 : simple-api : Raspberry - enabled, port: 8087, bind: 0.0.0.0, run as: admin + system.adapter.socketio.0 : socketio : Raspberry - enabled, port: 8084, bind: 192.168.178.42, run as: admin + system.adapter.telegram.0 : telegram : Raspberry - enabled, port: 8443, bind: 0.0.0.0 + system.adapter.web.0 : web : Raspberry - enabled, port: 8082, bind: 0.0.0.0, run as: admin ioBroker-Repositories ┌─────────┬─────────────────┬─────────────────────────────────────────────────────────┬──────────────┐ │ (index) │ name │ url │ auto upgrade │ ├─────────┼─────────────────┼─────────────────────────────────────────────────────────┼──────────────┤ │ 0 │ 'stable' │ 'http://download.iobroker.net/sources-dist.json' │ false │ │ 1 │ 'Beta (latest)' │ 'http://download.iobroker.net/sources-dist-latest.json' │ false │ └─────────┴─────────────────┴─────────────────────────────────────────────────────────┴──────────────┘ Active repo(s): stable Upgrade policy: none Installed ioBroker-Adapters ┌─────────┬────────────────────────────────┬─────────────────┬──────────┬────────────────┐ │ (index) │ id │ name │ version │ upgrade policy │ ├─────────┼────────────────────────────────┼─────────────────┼──────────┼────────────────┤ │ 0 │ 'system.adapter.admin' │ 'admin' │ '8.0.20' │ 'none' │ │ 1 │ 'system.adapter.alexa2' │ 'alexa2' │ '3.28.3' │ 'none' │ │ 2 │ 'system.adapter.backitup' │ 'backitup' │ '4.0.3' │ 'none' │ │ 3 │ 'system.adapter.deconz' │ 'deconz' │ '1.7.4' │ 'none' │ │ 4 │ 'system.adapter.devices' │ 'devices' │ '3.0.2' │ 'none' │ │ 5 │ 'system.adapter.email' │ 'email' │ '3.0.0' │ 'none' │ │ 6 │ 'system.adapter.fritzdect' │ 'fritzdect' │ '2.6.2' │ 'none' │ │ 7 │ 'system.adapter.ical' │ 'ical' │ '1.21.0' │ 'none' │ │ 8 │ 'system.adapter.iqontrol' │ 'iqontrol' │ '3.0.0' │ 'none' │ │ 9 │ 'system.adapter.javascript' │ 'javascript' │ '10.2.4' │ 'none' │ │ 10 │ 'system.adapter.linux-control' │ 'linux-control' │ '1.1.5' │ 'none' │ │ 11 │ 'system.adapter.matter' │ 'matter' │ '1.3.1' │ 'none' │ │ 12 │ 'system.adapter.ping' │ 'ping' │ '3.1.1' │ 'none' │ │ 13 │ 'system.adapter.rpi2' │ 'rpi2' │ '3.0.2' │ 'none' │ │ 14 │ 'system.adapter.simple-api' │ 'simple-api' │ '3.0.7' │ 'none' │ │ 15 │ 'system.adapter.socketio' │ 'socketio' │ '7.1.3' │ 'none' │ │ 16 │ 'system.adapter.telegram' │ 'telegram' │ '5.0.5' │ 'none' │ │ 17 │ 'system.adapter.trashschedule' │ 'trashschedule' │ '5.3.0' │ 'none' │ │ 18 │ 'system.adapter.web' │ 'web' │ '8.0.0' │ 'none' │ │ 19 │ 'system.adapter.ws' │ 'ws' │ '4.1.0' │ 'none' │ └─────────┴────────────────────────────────┴─────────────────┴──────────┴────────────────┘ ioBroker-Adapter Versions and update status Used repository: stable Adapter "admin" : 8.0.14 , installed 8.0.20 Adapter "alexa2" : 3.28.3 , installed 3.28.3 Adapter "backitup" : 4.0.3 , installed 4.0.3 Adapter "deconz" : 1.7.4 , installed 1.7.4 Adapter "devices" : 1.2.14 , installed 3.0.2 Adapter "email" : 3.0.0 , installed 3.0.0 Adapter "fritzdect" : 2.6.2 , installed 2.6.2 Adapter "ical" : 1.21.0 , installed 1.21.0 Adapter "iqontrol" : 3.0.0 , installed 3.0.0 Adapter "javascript" : 10.1.3 , installed 10.2.4 Controller "js-controller": 7.2.2 , installed 7.2.2 Adapter "linux-control": 1.1.5 , installed 1.1.5 Adapter "matter" : 1.3.1 , installed 1.3.1 Adapter "ping" : 3.0.1 , installed 3.1.1 Adapter "rpi2" : 3.0.2 , installed 3.0.2 Adapter "simple-api" : 3.0.7 , installed 3.0.7 Adapter "socketio" : 7.1.3 , installed 7.1.3 Adapter "telegram" : 5.0.5 , installed 5.0.5 Adapter "trashschedule": 5.3.0 , installed 5.3.0 Adapter "web" : 8.0.0 , installed 8.0.0 Adapter "ws" : 4.1.0 , installed 4.1.0 Objects and States Please stand by - This may take a while Objects: 5943 States: 4307 *** OS-Repositories and Updates *** Hit:1 http://deb.debian.org/debian trixie InRelease Hit:2 http://deb.debian.org/debian trixie-updates InRelease Hit:3 http://deb.debian.org/debian-security trixie-security InRelease Hit:5 http://archive.raspberrypi.com/debian trixie InRelease Hit:6 https://deb.nodesource.com/node_24.x nodistro InRelease Hit:4 https://phoscon.de/apt/deconz generic InRelease Reading package lists... Pending systemupdates: 0 *** Listening Ports *** Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess udp UNCONN 0 0 0.0.0.0:47199 0.0.0.0:* users:(("avahi-daemon",pid=622,fd=14)) udp UNCONN 0 0 0.0.0.0:sunrpc 0.0.0.0:* users:(("rpcbind",pid=599,fd=5),("systemd",pid=1,fd=119)) udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:* users:(("io.matter.0",pid=1320,fd=39)) udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:* users:(("io.matter.0",pid=1320,fd=36)) udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:* users:(("avahi-daemon",pid=622,fd=12)) udp UNCONN 0 0 0.0.0.0:5540 0.0.0.0:* users:(("io.matter.0",pid=1320,fd=38)) udp UNCONN 0 0 0.0.0.0:1900 0.0.0.0:* users:(("io.deconz.0",pid=2665,fd=35)) udp UNCONN 0 0 0.0.0.0:1900 0.0.0.0:* users:(("deCONZ",pid=628,fd=16)) udp UNCONN 0 0 *:sunrpc *:* users:(("rpcbind",pid=599,fd=7),("systemd",pid=1,fd=125)) udp UNCONN 0 0 [fe80::d550:7796:a5d9:1f74]:dhcpv6-client *:* users:(("NetworkManager",pid=839,fd=24)) udp UNCONN 0 0 *:mdns *:* users:(("io.matter.0",pid=1320,fd=40)) udp UNCONN 0 0 *:mdns *:* users:(("io.matter.0",pid=1320,fd=37)) udp UNCONN 0 0 *:mdns *:* users:(("avahi-daemon",pid=622,fd=13)) udp UNCONN 0 0 *:5540 *:* users:(("io.matter.0",pid=1320,fd=35)) udp UNCONN 0 0 *:1900 *:* users:(("io.deconz.0",pid=2665,fd=39)) udp UNCONN 0 0 *:1900 *:* users:(("io.deconz.0",pid=2665,fd=38)) udp UNCONN 0 0 *:1900 *:* users:(("io.deconz.0",pid=2665,fd=37)) udp UNCONN 0 0 *:36772 *:* users:(("avahi-daemon",pid=622,fd=15)) tcp LISTEN 0 511 127.0.0.1:9001 0.0.0.0:* users:(("iobroker.js-con",pid=957,fd=23)) tcp LISTEN 0 511 127.0.0.1:9000 0.0.0.0:* users:(("iobroker.js-con",pid=957,fd=29)) tcp LISTEN 0 4096 0.0.0.0:sunrpc 0.0.0.0:* users:(("rpcbind",pid=599,fd=4),("systemd",pid=1,fd=118)) tcp LISTEN 0 50 0.0.0.0:http 0.0.0.0:* users:(("deCONZ",pid=628,fd=8)) tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* users:(("sshd",pid=970,fd=6)) tcp LISTEN 0 50 0.0.0.0:441 0.0.0.0:* users:(("deCONZ",pid=628,fd=10)) tcp LISTEN 0 511 192.168.178.42:8084 0.0.0.0:* users:(("io.socketio.0",pid=1377,fd=40)) tcp LISTEN 0 511 *:8087 *:* users:(("io.simple-api.0",pid=1340,fd=35)) tcp LISTEN 0 511 *:tproxy *:* users:(("io.admin.0",pid=1024,fd=37)) tcp LISTEN 0 511 *:8082 *:* users:(("io.web.0",pid=1407,fd=35)) tcp LISTEN 0 4096 [::]:sunrpc [::]:* users:(("rpcbind",pid=599,fd=6),("systemd",pid=1,fd=121)) tcp LISTEN 0 128 [::]:ssh [::]:* users:(("sshd",pid=970,fd=7)) *** Log File - Last 25 Lines *** 2026-09-30 00:00:00.387 - info: javascript.0 (1048) script.js.common.Check_Sensor_Log_Batterie.CL_Licht_erreichbar: Telegram-Meldung (Wieder online) gesendet für: WZ Stehlampe1, WZ Stehlampe2, Wohnzimmer_hinten, Stecker WZ Echo, Steckdose Trockner, Stecker_Computerzimmer_1_Eingang, Küche_BWM
bin jetzt erstmal wieder auf nodejs22 und das schaut schon besser aus. Die Werte sind wieder akzeptierbar.
Heute war der schon kurz nach dem reboot
Ist irrelevant. Da pendelt sich ein. Beobachte das mal nach 24 Stunden.
Linux-Werkzeugkasten:
https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
NodeJS Fixer Skript:
https://forum.iobroker.net/topic/68035/iob-node-fix-skript
iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh -
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?
-
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?
@jippsydigger [sagte]: Kann das jemand bestätigen, auch bei nativer Installation?
Kann das auf 2 Installationen in VM nicht bestätigen: Der Swap ist ungenutzt.
Produktive Installation mit 4 GB RAM für die VM (qemu):
-
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
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 Anmelden472
Online33.1k
Benutzer84.1k
Themen1.4m
Beiträge