NEWS
JS-Adapter startet ständig neu: heap out of memory
-
@thomas-braun said in JS-Adapter startet ständig neu: heap out of memory:
iob diag
Sorry hat sich nach einem Neustart des Pis erledigt.
Aber der JS Fehler ist immer noch da.
Es laufen nach der Neuinstallation nur folgende Adapter:- admin.0
- backitup.0
- javascript.0
Die Skripte sind weiterhin deaktiviert.
iob diag:
Skript v.2023-10-10 *** BASE SYSTEM *** cat: /sys/devices/virtual/dmi/id/sys_vendor: No such file or directory Hardware Vendor : Kernel : aarch64 Userland : arm64 Docker : v9.0.1 Virtualization : Docker Kernel : aarch64 Userland : arm64 Systemuptime and Load: 00:42:10 up 8:22, 0 user, load average: 1.45, 1.26, 1.15 CPU threads: 4 *** Time and Time Zones *** Fri Dec 1 23:42:10 UTC 2023 Sat Dec 2 00:42:10 CET 2023 CET +0100 Etc/UTC *** User and Groups *** root /root root *** X-Server-Setup *** X-Server: false Desktop: Terminal: *** MEMORY *** total used free shared buff/cache available Mem: 4.0G 1.8G 418M 43M 2.0G 2.3G Swap: 104M 104M 196K Total: 4.1G 1.9G 418M 3844 M total memory 1695 M used memory 1742 M active memory 1288 M inactive memory 398 M free memory 114 M buffer memory 1768 M swap cache 99 M total swap 99 M used swap 0 M free swap *** FILESYSTEM *** Filesystem Type Size Used Avail Use% Mounted on overlay overlay 367G 120G 233G 35% / tmpfs tmpfs 64M 0 64M 0% /dev shm tmpfs 64M 0 64M 0% /dev/shm /dev/root ext4 367G 120G 233G 35% /opt/iobroker tmpfs tmpfs 1.9G 0 1.9G 0% /proc/asound tmpfs tmpfs 1.9G 0 1.9G 0% /sys/firmware Messages concerning ext4 filesystem in dmesg: dmesg: read kernel buffer failed: Operation not permitted Show mounted filesystems \(real ones only\): TARGET SOURCE FSTYPE OPTIONS /usr/share/zoneinfo/Etc/UTC /dev/root[/usr/share/zoneinfo/Europe/Berlin] ext4 ro,noatime /opt/iobroker /dev/root[/docker/iobroker_stack/app/data] ext4 rw,noatime /etc/resolv.conf /dev/root[/var/lib/docker/containers/dbae87321dd4fe0d2db919b36c1a52a9c4066f5d25c9c11ad75bfc291fdafb0f/resolv.conf] ext4 rw,noatime /etc/hostname /dev/root[/var/lib/docker/containers/dbae87321dd4fe0d2db919b36c1a52a9c4066f5d25c9c11ad75bfc291fdafb0f/hostname] ext4 rw,noatime /etc/hosts /dev/root[/var/lib/docker/containers/dbae87321dd4fe0d2db919b36c1a52a9c4066f5d25c9c11ad75bfc291fdafb0f/hosts] ext4 rw,noatime Files in neuralgic directories: /var: 34M /var/ 31M /var/lib 19M /var/lib/apt/lists 19M /var/lib/apt 13M /var/lib/dpkg /opt/iobroker/backups: 2.2M /opt/iobroker/backups/ /opt/iobroker/iobroker-data: 298M /opt/iobroker/iobroker-data/ 280M /opt/iobroker/iobroker-data/files 67M /opt/iobroker/iobroker-data/files/javascript.admin 55M /opt/iobroker/iobroker-data/files/material 53M /opt/iobroker/iobroker-data/files/material/static The five largest files in iobroker-data are: 41M /opt/iobroker/iobroker-data/files/material/static/js/main.c5478f66.js.map 21M /opt/iobroker/iobroker-data/files/web.admin/static/js/main.aaea95f8.js.map 18M /opt/iobroker/iobroker-data/files/text2command.admin/static/js/main.274a4d8d.js.map 16M /opt/iobroker/iobroker-data/objects.jsonl 9.9M /opt/iobroker/iobroker-data/files/material/static/js/main.c5478f66.js USB-Devices by-id: USB-Sticks - Avoid direct links to /dev/* in your adapter setups, please always prefer the links 'by-id': find: '/dev/serial/by-id/': No such file or directory *** NodeJS-Installation *** /usr/bin/nodejs v18.19.0 /usr/bin/node v18.19.0 /usr/bin/npm 10.2.3 /usr/bin/npx 10.2.3 /usr/bin/corepack 0.22.0 nodejs: Installed: 18.19.0-1nodesource1 Candidate: 18.19.0-1nodesource1 Version table: *** 18.19.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 100 /var/lib/dpkg/status 18.18.2-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.18.1-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.18.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.17.1-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.17.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.16.1-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.16.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.15.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.14.2-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.14.1-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.14.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.13.0+dfsg1-1 500 500 http://deb.debian.org/debian bookworm/main arm64 Packages 18.13.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.12.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.11.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.10.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.9.1-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.9.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.8.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.7.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.6.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.5.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.4.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.3.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.2.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.1.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages 18.0.0-1nodesource1 500 500 https://deb.nodesource.com/node_18.x nodistro/main arm64 Packages Temp directories causing npm8 problem: 0 No problems detected Errors in npm tree: *** ioBroker-Installation *** ioBroker Status iobroker is running on this host. Objects type: jsonl States type: jsonl Core adapters versions js-controller: 5.0.16 admin: 6.12.0 javascript: 7.1.6 Adapters from github: 0 Adapter State system.adapter.adguard.0 : adguard : iobroker - disabled, compact disabled + system.adapter.admin.0 : admin : iobroker - enabled, compact disabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin system.adapter.alarm.0 : alarm : iobroker - disabled, compact disabled system.adapter.alexa2.0 : alexa2 : iobroker - disabled, compact disabled + system.adapter.backitup.0 : backitup : iobroker - enabled, compact disabled system.adapter.bidirectional-counter.0 : bidirectional-counter : iobroker - disabled, compact disabled system.adapter.device-reminder.0 : device-reminder : iobroker - disabled, compact disabled system.adapter.device-watcher.0 : device-watcher : iobroker - disabled, compact disabled system.adapter.discovery.0 : discovery : iobroker - disabled, compact disabled system.adapter.ems-esp.0 : ems-esp : iobroker - disabled, compact disabled system.adapter.evcc.0 : evcc : iobroker - disabled, compact disabled, port: 7070 system.adapter.followthesun.0 : followthesun : iobroker - disabled, compact disabled system.adapter.habpanel.0 : habpanel : iobroker - disabled system.adapter.history.0 : history : iobroker - disabled, compact disabled system.adapter.hm-rega.0 : hm-rega : iobroker - disabled, compact disabled system.adapter.hm-rpc.1 : hm-rpc : iobroker - disabled, compact disabled, port: 0 system.adapter.hue.0 : hue : iobroker - disabled, compact disabled, port: 443 system.adapter.influxdb.0 : influxdb : iobroker - disabled, compact disabled, port: 8086 system.adapter.influxdb.1 : influxdb : iobroker - disabled, compact disabled, port: 8086 system.adapter.iqontrol.0 : iqontrol : iobroker - disabled, compact disabled system.adapter.jarvis.0 : jarvis : iobroker - disabled, compact disabled + system.adapter.javascript.0 : javascript : iobroker - enabled, compact disabled system.adapter.material.0 : material : iobroker - disabled system.adapter.modbus.0 : modbus : iobroker - disabled, compact disabled system.adapter.mqtt.0 : mqtt : iobroker - disabled, compact disabled, port: 1883, bind: 0.0.0.0 system.adapter.sayit.0 : sayit : iobroker - disabled, compact disabled, port: 0 system.adapter.shuttercontrol.0 : shuttercontrol : iobroker - disabled, compact disabled system.adapter.telegram.0 : telegram : iobroker - disabled, compact disabled, port: 8443, bind: 0.0.0.0 system.adapter.text2command.0 : text2command : iobroker - disabled, compact disabled system.adapter.weatherunderground.0 : weatherunderground : iobroker - disabled, compact disabled system.adapter.weatherunderground.1 : weatherunderground : iobroker - disabled, compact disabled system.adapter.web.0 : web : iobroker - disabled, compact enabled (group 1), port: 8082, bind: 0.0.0.0 (SSL), run as: admin system.adapter.zigbee.0 : zigbee : iobroker - disabled, compact disabled, port: /dev/ttyAMA0 system.adapter.zigbee2mqtt.0 : zigbee2mqtt : iobroker - disabled, compact disabled system.adapter.zwave2.0 : zwave2 : iobroker - disabled, compact disabled + instance is alive Enabled adapters with bindings + system.adapter.admin.0 : admin : iobroker - enabled, compact disabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin system.adapter.web.0 : web : iobroker - disabled, compact enabled (group 1), port: 8082, bind: 0.0.0.0 (SSL), run as: admin ioBroker-Repositories stable : http://download.iobroker.net/sources-dist.json beta : http://download.iobroker.net/sources-dist-latest.json Active repo(s): stable Installed ioBroker-Instances Used repository: stable Adapter "adguard" : 0.0.8 , installed 0.0.8 Adapter "admin" : 6.12.0 , installed 6.12.0 Adapter "alarm" : 3.4.3 , installed 3.4.3 Adapter "alexa2" : 3.26.3 , installed 3.26.3 Adapter "backitup" : 2.8.7 , installed 2.8.7 Adapter "bidirectional-counter": 2.1.3, installed 2.1.3 Adapter "device-reminder": 3.0.0 , installed 3.0.0 Adapter "device-watcher": 2.9.6 , installed 2.9.6 Adapter "discovery" : 4.2.0 , installed 4.2.0 Adapter "ems-esp" : 2.6.1 , installed 2.6.1 Adapter "evcc" : 0.0.10 , installed 0.0.10 Adapter "followthesun" : 0.4.2 , installed 0.4.2 Adapter "habpanel" : 0.5.0 , installed 0.5.0 Adapter "history" : 3.0.1 , installed 3.0.1 Adapter "hm-rega" : 4.0.0 , installed 4.0.0 Adapter "hm-rpc" : 1.15.19 , installed 1.15.19 Adapter "hue" : 3.10.1 , installed 3.10.1 Adapter "influxdb" : 3.2.0 , installed 3.2.0 Adapter "iqontrol" : 2.3.0 , installed 2.3.0 Adapter "jarvis" : 3.1.8 , installed 3.1.8 Adapter "javascript" : 7.1.6 , installed 7.1.6 Controller "js-controller": 5.0.16 , installed 5.0.16 Adapter "material" : 1.3.1 , installed 1.3.1 Adapter "modbus" : 5.0.11 , installed 5.0.11 Adapter "mqtt" : 5.1.0 , installed 5.1.0 Adapter "shuttercontrol": 1.6.3 , installed 1.6.3 Adapter "simple-api" : 2.7.2 , installed 2.7.2 Adapter "socketio" : 6.6.0 , installed 6.6.0 Adapter "telegram" : 2.0.1 , installed 2.0.1 Adapter "text2command" : 3.0.2 , installed 3.0.2 Adapter "weatherunderground": 3.6.0, installed 3.6.0 Adapter "web" : 6.1.10 , installed 6.1.10 Adapter "ws" : 2.5.8 , installed 2.5.8 Adapter "zigbee" : 1.8.24 , installed 1.8.24 Adapter "zigbee2mqtt" : 2.13.3 , installed 2.13.3 Adapter "zwave2" : 3.1.0 , installed 3.1.0 Objects and States Please stand by - This may take a while Objects: 11697 States: 10875 *** OS-Repositories and Updates *** Hit:1 http://deb.debian.org/debian bookworm InRelease Hit:2 http://deb.debian.org/debian bookworm-updates InRelease Hit:3 http://deb.debian.org/debian-security bookworm-security InRelease Hit:4 https://deb.nodesource.com/node_18.x nodistro InRelease Reading package lists... Pending Updates: 0 *** Listening Ports *** Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 1010 834014 - tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1010 834021 - tcp 0 0 127.0.0.11:39871 0.0.0.0:* LISTEN 0 833571 - tcp6 0 0 :::8081 :::* LISTEN 1010 835040 - udp 0 0 127.0.0.11:44813 0.0.0.0:* 0 833570 - *** Log File - Last 25 Lines *** 2023-12-02 00:42:09.539 - error: host.iobroker Caught by controller[23]: 23: 0x101edb0 v8::internal::JsonParser<unsigned short>::ParseJsonValue() [io.javascript.0] 2023-12-02 00:42:09.539 - error: host.iobroker Caught by controller[24]: 24: 0x101f2f0 v8::internal::JsonParser<unsigned short>::ParseJson() [io.javascript.0] 2023-12-02 00:42:09.539 - error: host.iobroker Caught by controller[25]: 25: 0xdcc460 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [io.javascript.0] 2023-12-02 00:42:09.539 - error: host.iobroker Caught by controller[26]: 26: 0x167c62c [io.javascript.0] 2023-12-02 00:42:09.539 - warn: host.iobroker instance system.adapter.javascript.0 terminated due to SIGABRT 2023-12-02 00:42:56.132 - error: host.iobroker Caught by controller[0]: <--- Last few GCs ---> 2023-12-02 00:42:56.134 - error: host.iobroker Caught by controller[0]: of marking 163 ms) (average mu = 0.755, current mu = 0.754) finalize incremen[2987:0x1aa44870] 10656 ms: Mark-sweep 67.5 (97.7) -> 60.9 (101.0) MB, 41.9 / 0.0 ms (+ 9.8 ms in 24 steps since start of marking, biggest step 3.0 ms, walltime since start of marking 165 ms) (average mu = 0.801, current mu = 0.843) finalize increment[2987:0x1aa44870] 11119 ms: Mark-sweep 84.3 (107.9) -> 81.5 (119.4) MB, 148.3 / 0.0 ms (average mu = 0.728, current mu = 0.679) allocation failure; scavenge might not succeed 2023-12-02 00:42:56.135 - error: host.iobroker Caught by controller[0]: <--- JS stacktrace ---> 2023-12-02 00:42:56.135 - error: host.iobroker Caught by controller[0]: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 2023-12-02 00:42:56.135 - error: host.iobroker Caught by controller[1]: 1: 0xb7f974 node::Abort() [io.javascript.0] 2023-12-02 00:42:56.136 - error: host.iobroker Caught by controller[2]: 2: 0xa97f08 [io.javascript.0] 2023-12-02 00:42:56.136 - error: host.iobroker Caught by controller[3]: 3: 0xd40e78 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [io.javascript.0] 2023-12-02 00:42:56.136 - error: host.iobroker Caught by controller[4]: 4: 0xd41048 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [io.javascript.0] 2023-12-02 00:42:56.136 - error: host.iobroker Caught by controller[5]: 5: 0xf1f5fc [io.javascript.0] 2023-12-02 00:42:56.137 - error: host.iobroker Caught by controller[6]: 6: 0xf31594 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [io.javascript.0] 2023-12-02 00:42:56.137 - error: host.iobroker Caught by controller[7]: 7: 0xf0d718 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [io.javascript.0] 2023-12-02 00:42:56.137 - error: host.iobroker Caught by controller[8]: 8: 0xf0e6f0 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [io.javascript.0] 2023-12-02 00:42:56.137 - error: host.iobroker Caught by controller[9]: 9: 0xef0cc0 v8::internal::Factory::AllocateRawWithAllocationSite(v8::internal::Handle<v8::internal::Map>, v8::internal::AllocationType, v8::internal::Handle<v8::internal::AllocationSite>) [io.javascript.0] 2023-12-02 00:42:56.137 - error: host.iobroker Caught by controller[10]: 10: 0xefb464 v8::internal::Factory::NewJSObjectFromMap(v8::internal::Handle<v8::internal::Map>, v8::internal::AllocationType, v8::internal::Handle<v8::internal::AllocationSite>) [io.javascript.0] 2023-12-02 00:42:56.138 - error: host.iobroker Caught by controller[11]: 11: 0x101e04c v8::internal::JsonParser<unsigned short>::BuildJsonObject(v8::internal::JsonParser<unsigned short>::JsonContinuation const&, v8::base::SmallVector<v8::internal::JsonProperty, 16ul, std::allocator<v8::internal::JsonProperty> > const&, v8::internal::Handle<v8::internal::Map>) [io.javascript.0] 2023-12-02 00:42:56.138 - error: host.iobroker Caught by controller[12]: 12: 0x101edb0 v8::internal::JsonParser<unsigned short>::ParseJsonValue() [io.javascript.0] 2023-12-02 00:42:56.138 - error: host.iobroker Caught by controller[13]: 13: 0x101f2f0 v8::internal::JsonParser<unsigned short>::ParseJson() [io.javascript.0] 2023-12-02 00:42:56.138 - error: host.iobroker Caught by controller[14]: 14: 0xdcc460 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [io.javascript.0] 2023-12-02 00:42:56.138 - error: host.iobroker Caught by controller[15]: 15: 0x167c62c [io.javascript.0] 2023-12-02 00:42:56.138 - warn: host.iobroker instance system.adapter.javascript.0 terminated due to SIGABRT======================= SUMMARY ======================= v.2023-10-10 Model : Raspberry Pi 4 Model B Rev 1.2 Kernel : aarch64 Userland : arm64 Docker : v9.0.1 Installation: Docker Kernel: aarch64 Userland: arm64 Timezone: Etc/UTC User-ID: 0 X-Server: false Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v18.19.0 /usr/bin/node v18.19.0 /usr/bin/npm 10.2.3 /usr/bin/npx 10.2.3 /usr/bin/corepack 0.22.0 Recommended versions are nodejs 18.19.0 and npm 10.2.3 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 4.0G 1.8G 426M 43M 1.9G 2.2G Swap: 104M 104M 196K Total: 4.1G 2.0G 427M Active iob-Instances: 3 Active repo(s): stable ioBroker Core: js-controller 5.0.16 admin 6.12.0 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : iobroker - enabled, compact disabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin system.adapter.web.0 : web : iobroker - disabled, compact enabled (group 1), port: 8082, bind: 0.0.0.0 (SSL), run as: admin Objects: 11697 States: 10875 Size of iob-Database: 16M /opt/iobroker/iobroker-data/objects.jsonl 3.2M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY =========================================== SUMMARY ======================= v.2023-10-10 Model : Raspberry Pi 4 Model B Rev 1.2 Kernel : aarch64 Userland : arm64 Docker : v9.0.1 Installation: Docker Kernel: aarch64 Userland: arm64 Timezone: Etc/UTC User-ID: 0 X-Server: false Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v18.19.0 /usr/bin/node v18.19.0 /usr/bin/npm 10.2.3 /usr/bin/npx 10.2.3 /usr/bin/corepack 0.22.0 Recommended versions are nodejs 18.19.0 and npm 10.2.3 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 4.0G 1.8G 426M 43M 1.9G 2.2G Swap: 104M 104M 196K Total: 4.1G 2.0G 427M Active iob-Instances: 3 Active repo(s): stable ioBroker Core: js-controller 5.0.16 admin 6.12.0 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : iobroker - enabled, compact disabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin system.adapter.web.0 : web : iobroker - disabled, compact enabled (group 1), port: 8082, bind: 0.0.0.0 (SSL), run as: admin Objects: 11697 States: 10875 Size of iob-Database: 16M /opt/iobroker/iobroker-data/objects.jsonl 3.2M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Docker auf einem Raspberry?
Ich muss hier weg... -
Docker auf einem Raspberry?
Ich muss hier weg...@thomas-braun Das ganze hat Jahre lang wunderbar funktioniert.
Habe ich so selbst in der Industrie schon gesehen.
Sehr praktisch zum testen und bereitsellen von Software, ohne sich das System voll zu müllen, da man sie Software Restlos entfernen kann. -
@thomas-braun Das ganze hat Jahre lang wunderbar funktioniert.
Habe ich so selbst in der Industrie schon gesehen.
Sehr praktisch zum testen und bereitsellen von Software, ohne sich das System voll zu müllen, da man sie Software Restlos entfernen kann.Zum anschauen und testen von irgendwas ist das sinnvoll. Fur dauerhaften Betrieb ist es nur eine entbehrliche weitere Softwareschicht, die auch noch richtig unterhalten werden will.
Ist mir für den ioBroker nur ein unnötiger Ressourcenfresser.Btw: Dir geht der für nodejs allokierte Arbeitsspeicher aus... :-)
-
Zum anschauen und testen von irgendwas ist das sinnvoll. Fur dauerhaften Betrieb ist es nur eine entbehrliche weitere Softwareschicht, die auch noch richtig unterhalten werden will.
Ist mir für den ioBroker nur ein unnötiger Ressourcenfresser.Btw: Dir geht der für nodejs allokierte Arbeitsspeicher aus... :-)
@thomas-braun Es liegen 300MB freien RAM und 2GB an Verfügbaren RAM rum.
Wenn ich den Container ohne Backup starte und dann JS laufen lasse habe ich das Problem nicht.
Dann wird wohl docker nicht das Problem sein, sondern irgendwelche vorhandenen Daten oder ein Installationsprozess.
Die Frage ist nur warum dieser Fehler bei einer Neuinstallation + Backup wieder "eingebaut" wird.Btw:
Viele vergleichen Docker beim Resourcenverbrauch gerne mit VM, habe ich früher auch gemacht. Ich musste aber feststellen, dass dies nicht der Fall ist und der Overhead realtiv gering ist, wenn man weiss wie man die Container aufzubauen hat.
One program per container.
Wenn man sich daran hält ist man "fast" auf der Ebene eines chroot mit einem netten Verwaltungs und Sicherheitsbonus.
Da iobroker mit seinen Adaptern recht Modular aufgebaut ist mag diese Philosophie hier nicht ganz zutreffen, aber das erklärt das oben beschriebene Verhalten trotzdem nicht. -
@thomas-braun Es liegen 300MB freien RAM und 2GB an Verfügbaren RAM rum.
Wenn ich den Container ohne Backup starte und dann JS laufen lasse habe ich das Problem nicht.
Dann wird wohl docker nicht das Problem sein, sondern irgendwelche vorhandenen Daten oder ein Installationsprozess.
Die Frage ist nur warum dieser Fehler bei einer Neuinstallation + Backup wieder "eingebaut" wird.Btw:
Viele vergleichen Docker beim Resourcenverbrauch gerne mit VM, habe ich früher auch gemacht. Ich musste aber feststellen, dass dies nicht der Fall ist und der Overhead realtiv gering ist, wenn man weiss wie man die Container aufzubauen hat.
One program per container.
Wenn man sich daran hält ist man "fast" auf der Ebene eines chroot mit einem netten Verwaltungs und Sicherheitsbonus.
Da iobroker mit seinen Adaptern recht Modular aufgebaut ist mag diese Philosophie hier nicht ganz zutreffen, aber das erklärt das oben beschriebene Verhalten trotzdem nicht.@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Die Frage ist nur warum dieser Fehler bei einer Neuinstallation + Backup wieder "eingebaut" wird.
Nach einer Neuinstallation ohne Backup, ist da nicht viel los. Mit anderen Worten da wird nicht zu viel Speicher benötigt.
Wenn das Backup drin ist, laufen ja wieder Adapter, Skripte,... und das braucht halt Speicher. Und mit jeder Weiterentwicklung von Adaptern gibt es mehr Funktionalität. An der Sicherheit wird auch gearbeitet - und das braucht halt mehr Speicher, als noch vor 5 Jahren.
Aber das ist nicht nur beim ioBroker so. Gleiches Verhalten hast du auch bei Windows, Windows-Programmen und auch bi Linux. Früher war alles gefühlt schlanker, platzsparender und weniger speicherhungrig. Aber so ist nun mal der Lauf.
Dir geht mit der Variante ioBroker im Docker einfach der Speicher auf deinem Raspi aus, auch bi einem 4GB Model. Ich hatte den ioBroker mehrere Jahre auf meinem Raspi (4GB) nornal, ohne Docker laufen mit mehr als 20 Adaptern, ohne Problem.
Aus meiner Sicht:
-
wenn du weiterhin mit Docker arbeiten willst/musst dann brauchst du mehr RAM
-
RAM erweitern auf einem Raspi soll zwar gehen, mir aber zu kompliziert
-
neuer Raspi mit 8GB oder lieber gleich ein NUC
Die 3 Punkte unter dem Gesichtspunkt, dass du mit Docker arbeiten willst. Alternativ verzichte auf Docker (zumindest ohne ioBroker, nur für andere Projekte).
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
-
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Die Frage ist nur warum dieser Fehler bei einer Neuinstallation + Backup wieder "eingebaut" wird.
Nach einer Neuinstallation ohne Backup, ist da nicht viel los. Mit anderen Worten da wird nicht zu viel Speicher benötigt.
Wenn das Backup drin ist, laufen ja wieder Adapter, Skripte,... und das braucht halt Speicher. Und mit jeder Weiterentwicklung von Adaptern gibt es mehr Funktionalität. An der Sicherheit wird auch gearbeitet - und das braucht halt mehr Speicher, als noch vor 5 Jahren.
Aber das ist nicht nur beim ioBroker so. Gleiches Verhalten hast du auch bei Windows, Windows-Programmen und auch bi Linux. Früher war alles gefühlt schlanker, platzsparender und weniger speicherhungrig. Aber so ist nun mal der Lauf.
Dir geht mit der Variante ioBroker im Docker einfach der Speicher auf deinem Raspi aus, auch bi einem 4GB Model. Ich hatte den ioBroker mehrere Jahre auf meinem Raspi (4GB) nornal, ohne Docker laufen mit mehr als 20 Adaptern, ohne Problem.
Aus meiner Sicht:
-
wenn du weiterhin mit Docker arbeiten willst/musst dann brauchst du mehr RAM
-
RAM erweitern auf einem Raspi soll zwar gehen, mir aber zu kompliziert
-
neuer Raspi mit 8GB oder lieber gleich ein NUC
Die 3 Punkte unter dem Gesichtspunkt, dass du mit Docker arbeiten willst. Alternativ verzichte auf Docker (zumindest ohne ioBroker, nur für andere Projekte).
Ro75.
@ro75 Im Log ist zu erkennen das nach dem Backup kein Adapter läuft und auch kein Skript.
Das bedeutet auch das kein RAM benötigt wird.Nachmal, ALLE Adapter und Skripte sind nach dem Backup DEAKTIVIERT.
Erst wenn ich nun den JS Adapter aktiviere und ich meine nur den JS Adapter, kommt der Fehler wieder.
Wenn ich das Backup NICHT einspiele und selber ALLE Adapter installiere und aktiviere, kommt der Fehler nicht.
Inzwischen laufen sogar wieder Sktipte ohne Fehlermeldung.
Kein anderer Docker Container oder Prozess hat Probleme auf dem System.
Besonders InfluxDB musste dann Fehler ohne Ende schmeißen.Ich glaube aber dem Fehler näher zu kommen.
Wie kann man von allen Objekten den Raum und die Funktion aufeinmal entfernen, ohne das Objekt selber oder andere Einstellungen von den Objekten zu löschen?
Ich möchte nicht meine Zeit damit verbringen alle Objekte wieder neu einzustellen bzgl. InfluxDB und co.
Zudem denke ich das es auch im interesse der Community ist, wenn man der Ursache genau auf den Grund geht.Bzgl. der RAM verbrauchs:
Ich bin Programmierer, ich habe bisher nur ein paar flüchtige Blicke in die Adapterprogrammierung geworfen. Trotzdem versteht ich nicht was dafür sorge, dass mein Weihnachtsscript (aus meinem ersten Post), den RAM Verbrauch vom JS Adapter um ca. 125MB steigen lässt. Da sind gerade mal 3 Integer Variablen, 6 Funktionsaufrufe und 3 Vergleiche drin. -
-
Hi, ich habe seit kurzem ein Problem mit meiner ioBroker Instanz.
Mir ist aufgefallen, dass sich mein Log mit Fehlermeldungen füllt und der JS-Adapter immer neustartet.Ich habe auch schon meine Skripte deaktiviert, ohne Erfolg.
Host: Raspberry Pi 4 (4GB)
JS-Controller version: 5.0.16 (docker (official image - v9.0.1))
Node version: v18.18.2
Operating system: raspberrypi os bookworm arm64 6.1.21-v8+ (Docker version 24.0.7, build afdd53b)Log:
host.iobroker 2023-11-27 00:40:15.140 warn instance system.adapter.javascript.0 terminated due to SIGABRT host.iobroker 2023-11-27 00:40:15.139 error Caught by controller[10]: 16: 0x167960c [io.javascript.0] host.iobroker 2023-11-27 00:40:15.139 error Caught by controller[9]: 15: 0xdc93f8 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.139 error Caught by controller[8]: 14: 0x101c2c8 v8::internal::JsonParser<unsigned short>::ParseJson() [io.javascript.0] host.iobroker 2023-11-27 00:40:15.139 error Caught by controller[7]: 13: 0x101b648 v8::internal::JsonParser<unsigned short>::ParseJsonValue() [io.javascript.0] host.iobroker 2023-11-27 00:40:15.139 error Caught by controller[6]: 12: 0x101a0e8 v8::internal::JsonParser<unsigned short>::MakeString(v8::internal::JsonString const&, v8::internal::Handle<v8::internal::String>) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.138 error Caught by controller[5]: 11: 0xee6e84 v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString(int, v8::internal::AllocationType) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.137 error Caught by controller[4]: 10: 0xee4af4 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.137 error Caught by controller[3]: 9: 0xeed87c v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.136 error Caught by controller[2]: 8: 0xf0b6c8 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.136 error Caught by controller[1]: 7: 0xf0a6f0 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.136 error Caught by controller[0]: 6: 0xf2e56c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.136 error Caught by controller[0]: 5: 0xf1c5d4 [io.javascript.0] host.iobroker 2023-11-27 00:40:15.135 error Caught by controller[0]: 4: 0xd3dfe0 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.135 error Caught by controller[0]: 3: 0xd3de10 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [io.javascript.0] host.iobroker 2023-11-27 00:40:15.135 error Caught by controller[0]: 2: 0xa93f08 [io.javascript.0] host.iobroker 2023-11-27 00:40:15.135 error Caught by controller[0]: 1: 0xb72e9c node::Abort() [io.javascript.0] host.iobroker 2023-11-27 00:40:15.135 error Caught by controller[0]: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory host.iobroker 2023-11-27 00:40:15.135 error Caught by controller[0]: <--- JS stacktrace ---> host.iobroker 2023-11-27 00:40:15.134 error Caught by controller[0]: of marking 130 ms) (average mu = 0.732, current mu = 0.751) finalize increment[1633:0x81873d0] 11852 ms: Mark-sweep 60.5 (97.8) -> 60.3 (99.3) MB, 27.5 / 0.0 ms (+ 2.7 ms in 11 steps since start of marking, biggest step 0.5 ms, walltime since start of marking 112 ms) (average mu = 0.903, current mu = 0.959) finalize incremental[1633:0x81873d0] 12487 ms: Mark-sweep 83.1 (106.0) -> 80.9 (119.8) MB, 167.3 / 0.0 ms (average mu = 0.809, current mu = 0.737) allocation failure; scavenge might not succeed host.iobroker 2023-11-27 00:40:15.133 error Caught by controller[0]: <--- Last few GCs --->Einer meiner Skripte:
code_on(["followthesun.0.current.altitude"], function (data) { var altitude = getState('followthesun.0.current.altitude').val; var hour = new Date().getHours(); var State = 0; if (( 6 < hour && hour < 22) && altitude < 0) { State = 1; } setState('hm-rpc.1.NEQ0369977.1.STATE', State); setState('hm-rpc.1.NEQ1660368.1.STATE', State); setState('hm-rpc.1.NEQ1660368.2.STATE', State); setState('hm-rpc.1.NEQ0369977.1.STATE', State); });@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
JavaScript heap out of memory
soweit ich weiß bezieht sich das nicht (nur) auf den javascript Adapter, sondern auf alles was mit js läuft.
-
@ro75 Im Log ist zu erkennen das nach dem Backup kein Adapter läuft und auch kein Skript.
Das bedeutet auch das kein RAM benötigt wird.Nachmal, ALLE Adapter und Skripte sind nach dem Backup DEAKTIVIERT.
Erst wenn ich nun den JS Adapter aktiviere und ich meine nur den JS Adapter, kommt der Fehler wieder.
Wenn ich das Backup NICHT einspiele und selber ALLE Adapter installiere und aktiviere, kommt der Fehler nicht.
Inzwischen laufen sogar wieder Sktipte ohne Fehlermeldung.
Kein anderer Docker Container oder Prozess hat Probleme auf dem System.
Besonders InfluxDB musste dann Fehler ohne Ende schmeißen.Ich glaube aber dem Fehler näher zu kommen.
Wie kann man von allen Objekten den Raum und die Funktion aufeinmal entfernen, ohne das Objekt selber oder andere Einstellungen von den Objekten zu löschen?
Ich möchte nicht meine Zeit damit verbringen alle Objekte wieder neu einzustellen bzgl. InfluxDB und co.
Zudem denke ich das es auch im interesse der Community ist, wenn man der Ursache genau auf den Grund geht.Bzgl. der RAM verbrauchs:
Ich bin Programmierer, ich habe bisher nur ein paar flüchtige Blicke in die Adapterprogrammierung geworfen. Trotzdem versteht ich nicht was dafür sorge, dass mein Weihnachtsscript (aus meinem ersten Post), den RAM Verbrauch vom JS Adapter um ca. 125MB steigen lässt. Da sind gerade mal 3 Integer Variablen, 6 Funktionsaufrufe und 3 Vergleiche drin.@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Ich bin Programmierer, ich habe bisher nur ein paar flüchtige Blicke in die Adapterprogrammierung geworfen. Trotzdem versteht ich nicht was dafür sorge, dass mein Weihnachtsscript (aus meinem ersten Post), den RAM Verbrauch vom JS Adapter um ca. 125MB steigen lässt. Da sind gerade mal 3 Integer Variablen, 6 Funktionsaufrufe und 3 Vergleiche drin
Ich programmiere auch seit 20 Jahren - nur Windows, seit 2020 auch JS, dank ioBroker. Aber um zu schauen was bei dir ist, müsste man schon das vollständige Skript mal sehen.
Ro75.
-
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
JavaScript heap out of memory
soweit ich weiß bezieht sich das nicht (nur) auf den javascript Adapter, sondern auf alles was mit js läuft.
@homoran said in JS-Adapter startet ständig neu: heap out of memory:
soweit ich weiß bezieht sich das nicht (nur) auf den javascript Adapter, sondern auf alles was mit js läuft.
Dann stellt sich nur immernoch die Frage warum nur der JS Adapter davon betroffen ist.
Soweit ich weiss läuft das gesamte ioBroker-System auf javascript.Und dies nicht bei einer Neuinstallation der Fall ist, sondern nur beim wiederherstellen alter Daten.
-
@homoran said in JS-Adapter startet ständig neu: heap out of memory:
soweit ich weiß bezieht sich das nicht (nur) auf den javascript Adapter, sondern auf alles was mit js läuft.
Dann stellt sich nur immernoch die Frage warum nur der JS Adapter davon betroffen ist.
Soweit ich weiss läuft das gesamte ioBroker-System auf javascript.Und dies nicht bei einer Neuinstallation der Fall ist, sondern nur beim wiederherstellen alter Daten.
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
warum nur der JS Adapter davon betroffen ist.
die Meldung kommt vom Controller!
-
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
warum nur der JS Adapter davon betroffen ist.
die Meldung kommt vom Controller!
@homoran Das ist mir bewusst, nur müsste dieser ja auch bei andere Adapter diese Fehlermeldung ausgeben wenn ich sie starte und zu wenig RAM zur Verfügung stehen.
Also z.b. die Reihenfolge ändere in der ich sie starte.Wenn ich das Backup einspiele und alle Adapter die man deaktivieren kann deaktiviere.
Braucht ioBroker ca. 200MB.
Alle Adapter die deaktiviert sind ohne den JS-Adapter brauchen im laufenden Zustand ca. 1,2GB.
Der JS Adapter brauch ca. 250MB mit einem Skript (Auf einem neu installieren ioBroker).
Wenn also kein Adapter läuft, also 1,2GB zur Verfügung stehen und der JS Adapter ca. 250MB braucht, kann iobroker nicht genug RAM allokieren?
Bei einem Neuinstallieren System klappt es aber(inklusive aller anderen Adapter die ca. 1,2GB brauchen)!!! -
@homoran Das ist mir bewusst, nur müsste dieser ja auch bei andere Adapter diese Fehlermeldung ausgeben wenn ich sie starte und zu wenig RAM zur Verfügung stehen.
Also z.b. die Reihenfolge ändere in der ich sie starte.Wenn ich das Backup einspiele und alle Adapter die man deaktivieren kann deaktiviere.
Braucht ioBroker ca. 200MB.
Alle Adapter die deaktiviert sind ohne den JS-Adapter brauchen im laufenden Zustand ca. 1,2GB.
Der JS Adapter brauch ca. 250MB mit einem Skript (Auf einem neu installieren ioBroker).
Wenn also kein Adapter läuft, also 1,2GB zur Verfügung stehen und der JS Adapter ca. 250MB braucht, kann iobroker nicht genug RAM allokieren?
Bei einem Neuinstallieren System klappt es aber(inklusive aller anderen Adapter die ca. 1,2GB brauchen)!!!@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
nur müsste dieser ja auch bei andere Adapter diese Fehlermeldung ausgeben wenn ich sie starte und zu wenig RAM zur Verfügung stehen.
ich kenne mich viel zu wenig damit aus.
Ich weiss auch nicht eas sich hinter Heap verbirgt. -
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
nur müsste dieser ja auch bei andere Adapter diese Fehlermeldung ausgeben wenn ich sie starte und zu wenig RAM zur Verfügung stehen.
ich kenne mich viel zu wenig damit aus.
Ich weiss auch nicht eas sich hinter Heap verbirgt.@homoran In der Programmierung gibt es zwei Speicherarten:
-
Stack
Wie der Name schon sagt handelt es sich um einen Stapel, auf diesen werden bei Funktionsaufrufen oder Sprüngen Daten abgelegt, die beim zurückkehren wieder heruntergenommen werden, um mit ihnen weiter zu arbeiten.
Stell es dir wie ein Aktenstapel vor auf dem du deine Dokumente ablegst, weil dein Chef gerade etwas anderes von dir will und die du dann wieder runternehmen kannst wenn du mit der neuen Aufgabe fertig geworden bist. Er sorgt dafür, dass du dich mit den Daten beschäftigst mit den du als letztes zu tun hattest.
Jeder Prozess besitzt einen eigenen Stack.
Im Stack liegen nur Daten/Variablen die für die jeweilige Funktion relevant sind.
Wenn die Funktion fertig ist werden die nötigen Daten zuück gegeben, alle anderen Daten der Funktion werden verworfen. -
Heap
Beim Heap handelt es sich bei modernen Systemen um einen dynamischen Speicher, auf dem freier Speicherplatz addressiert/angefordert werden kann. Wenn du Speicher benötigst, bittest du das OS um den gewünschten Speicherplatz. Dieser wird dann, wenn er zur Verfügung steht für deine Daten reserviert. Solange du diese Daten nicht wieder frei gibst, kann kein anderes Programm/Process diesen Speicher benutzen.
Alles was nicht auf dem Stack liegt ist im Heap.
Dazu gehören grob alle Daten die über einen Funktionsaufruf hinaus zur Verfügung stehen, weil sie z.B. von mehreren Prozessen oder Threads gebraucht werden.
Das zum Heap ist sehr grob, ohne Paging/Swap oder Memory leak.
Zum meinem Problem:
Es steht nicht genug RAM zur Verfügung, obwohl 300MB absolut ungenutzt sind und ca. 1,2GB die zwar mal genutzt wurden aber wieder freigegeben wurden.Deshalb stellt sich die Frage warum brauch ioBroker um den JS Adapter zu starten mehr als 1,5GB RAM.
Und warum braucht er dies nur nachdem ich das Backup eingespielt habe, nicht aber wenn ich alles per Hand aufsetzt.
-
-
@homoran In der Programmierung gibt es zwei Speicherarten:
-
Stack
Wie der Name schon sagt handelt es sich um einen Stapel, auf diesen werden bei Funktionsaufrufen oder Sprüngen Daten abgelegt, die beim zurückkehren wieder heruntergenommen werden, um mit ihnen weiter zu arbeiten.
Stell es dir wie ein Aktenstapel vor auf dem du deine Dokumente ablegst, weil dein Chef gerade etwas anderes von dir will und die du dann wieder runternehmen kannst wenn du mit der neuen Aufgabe fertig geworden bist. Er sorgt dafür, dass du dich mit den Daten beschäftigst mit den du als letztes zu tun hattest.
Jeder Prozess besitzt einen eigenen Stack.
Im Stack liegen nur Daten/Variablen die für die jeweilige Funktion relevant sind.
Wenn die Funktion fertig ist werden die nötigen Daten zuück gegeben, alle anderen Daten der Funktion werden verworfen. -
Heap
Beim Heap handelt es sich bei modernen Systemen um einen dynamischen Speicher, auf dem freier Speicherplatz addressiert/angefordert werden kann. Wenn du Speicher benötigst, bittest du das OS um den gewünschten Speicherplatz. Dieser wird dann, wenn er zur Verfügung steht für deine Daten reserviert. Solange du diese Daten nicht wieder frei gibst, kann kein anderes Programm/Process diesen Speicher benutzen.
Alles was nicht auf dem Stack liegt ist im Heap.
Dazu gehören grob alle Daten die über einen Funktionsaufruf hinaus zur Verfügung stehen, weil sie z.B. von mehreren Prozessen oder Threads gebraucht werden.
Das zum Heap ist sehr grob, ohne Paging/Swap oder Memory leak.
Zum meinem Problem:
Es steht nicht genug RAM zur Verfügung, obwohl 300MB absolut ungenutzt sind und ca. 1,2GB die zwar mal genutzt wurden aber wieder freigegeben wurden.Deshalb stellt sich die Frage warum brauch ioBroker um den JS Adapter zu starten mehr als 1,5GB RAM.
Und warum braucht er dies nur nachdem ich das Backup eingespielt habe, nicht aber wenn ich alles per Hand aufsetzt.
@smhrambo Danke für die Erklärung.
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
obwohl 300MB absolut ungenutzt sind und ca. 1,2GB die zwar mal genutzt wurden aber wieder freigegeben wurden.
Deshalb stellt sich die Frage warum brauch ioBroker um den JS Adapter zu starten mehr als 1,5GB RAMist bei 1200 zwar wahrscheinlich eher unerheblich, aber ich war bisher der Meinung dass der mem free im mem available enthslten ist, also die beiden Werte nicht aufaddiert werden dürfen
beim Start von js werden allerdings alle startenden Skripte neu kompiliert
-
-
@smhrambo Danke für die Erklärung.
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
obwohl 300MB absolut ungenutzt sind und ca. 1,2GB die zwar mal genutzt wurden aber wieder freigegeben wurden.
Deshalb stellt sich die Frage warum brauch ioBroker um den JS Adapter zu starten mehr als 1,5GB RAMist bei 1200 zwar wahrscheinlich eher unerheblich, aber ich war bisher der Meinung dass der mem free im mem available enthslten ist, also die beiden Werte nicht aufaddiert werden dürfen
beim Start von js werden allerdings alle startenden Skripte neu kompiliert
@homoran Kann gut sein, ich habe damals gelernt, das free der Speicher ist, der theoretisch aus dem System entfernt werden kann.
Aber wie du schon sagtest wären da immernoch 1,2GB.Das die Skripte neu kompiliert werden sollten, wenn sie aktiviert sind, weiss ich.
Aber nochmal, alle Skripte sind deaktiviert, alle haben ein rotes Play-Symbol.
Demensprechend sollte sie doch nicht neu kompiliert werden.Ich habe das gerade noch mal getestet, im aktuellen System ohne Backup, auf dem alles läuft.
Mit aktivierten Skripte finde ich mit Loglevel silly keine informationen ob die Skripte bei einem Neustart vom JS Adapter neu kompiliert werden.
Demenspechend kann ich darüber keine handfeste Aussage machen.Im aktuellen System ohne Backup mit 19 aktiven Adaptern (20 Prozesse) läuft es.
Ich habe nur keine Lust alle Einstellungen wieder von Hand vorzunehmen.
Das Problem liegt irgendwo in den wiederhergestellten Daten/Einstellungen und kann dementsprechend jederzeit wieder auftreten, wenn man die Ursache nicht kennt. -
@homoran Kann gut sein, ich habe damals gelernt, das free der Speicher ist, der theoretisch aus dem System entfernt werden kann.
Aber wie du schon sagtest wären da immernoch 1,2GB.Das die Skripte neu kompiliert werden sollten, wenn sie aktiviert sind, weiss ich.
Aber nochmal, alle Skripte sind deaktiviert, alle haben ein rotes Play-Symbol.
Demensprechend sollte sie doch nicht neu kompiliert werden.Ich habe das gerade noch mal getestet, im aktuellen System ohne Backup, auf dem alles läuft.
Mit aktivierten Skripte finde ich mit Loglevel silly keine informationen ob die Skripte bei einem Neustart vom JS Adapter neu kompiliert werden.
Demenspechend kann ich darüber keine handfeste Aussage machen.Im aktuellen System ohne Backup mit 19 aktiven Adaptern (20 Prozesse) läuft es.
Ich habe nur keine Lust alle Einstellungen wieder von Hand vorzunehmen.
Das Problem liegt irgendwo in den wiederhergestellten Daten/Einstellungen und kann dementsprechend jederzeit wieder auftreten, wenn man die Ursache nicht kennt.@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Das Problem liegt irgendwo in den wiederhergestellten Daten/Einstellungen und kann dementsprechend jederzeit wieder auftreten, wenn man die Ursache nicht kennt.
und deswegen hatte ich mich hier gemeldet und darauf hingewiesen dass die Meldung nicht unbedingt alleine durch den js-Adapter verursacht werden muss
-
Eine kleine Sache dir mir aufgefallen ist.
Mein kleiner Weihnachtskript vom ersten Post.
Weil setState sich gemeldet hat und gerne boolean statt integer haben wollte, habe
Ich die Variable State geändert, dass diese mit true/false läuft statt mit 1/0.Daraus ergibt sich ein RAM Erspanis von ca. 100MB.
WTF -
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Das Problem liegt irgendwo in den wiederhergestellten Daten/Einstellungen und kann dementsprechend jederzeit wieder auftreten, wenn man die Ursache nicht kennt.
und deswegen hatte ich mich hier gemeldet und darauf hingewiesen dass die Meldung nicht unbedingt alleine durch den js-Adapter verursacht werden muss
@homoran Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.
Kein anderer Adapter scheint diese Daten zu benötigen oder der JS Adapter interpretiert die Daten falsch.
Ich habe eine Idee, dehalb meine Frage wie ich die Objekte von bestimmten Daten befreien kann.Ich habe versucht eine Art semantisches Modell meines Hauses zu erzeugen.
Den JS Adapter habe ich die letzten Monate nicht benutzt,
weil ich die Hardware für die ich die Skripte brauche reparieren musste.
Nun ist Weihnachten und der JS Adapter soll mein Weihnachtsprogramm laufen lassen und nun läuft er nicht mehr.
Also habe ich inzwischen den Verdacht, dass es an der Zuordnung in der ioBroker Aufzählungen liegen könnte.Ganz wilde Theorie:
Vielleicht gibt es durch die Zuordnung eine Schleife, da ich mit Stockwerken und Räumen gearbeitet habe. -
@homoran Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.
Kein anderer Adapter scheint diese Daten zu benötigen oder der JS Adapter interpretiert die Daten falsch.
Ich habe eine Idee, dehalb meine Frage wie ich die Objekte von bestimmten Daten befreien kann.Ich habe versucht eine Art semantisches Modell meines Hauses zu erzeugen.
Den JS Adapter habe ich die letzten Monate nicht benutzt,
weil ich die Hardware für die ich die Skripte brauche reparieren musste.
Nun ist Weihnachten und der JS Adapter soll mein Weihnachtsprogramm laufen lassen und nun läuft er nicht mehr.
Also habe ich inzwischen den Verdacht, dass es an der Zuordnung in der ioBroker Aufzählungen liegen könnte.Ganz wilde Theorie:
Vielleicht gibt es durch die Zuordnung eine Schleife, da ich mit Stockwerken und Räumen gearbeitet habe.@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.
Ich kann vollkommen daneben liegen, aber ih denke hier liegt dein Denkfehler.
Wer sagt dir dass der Adapter so viel RAM benötigt, wenn der js HEAP für alle javascript Aktionen (auch im Grundsystem) gilt? -
@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:
Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.
Ich kann vollkommen daneben liegen, aber ih denke hier liegt dein Denkfehler.
Wer sagt dir dass der Adapter so viel RAM benötigt, wenn der js HEAP für alle javascript Aktionen (auch im Grundsystem) gilt?@homoran Kannst du mir deinen Gedankengang näher erläutern.
Also wenn ich den JS Adapter aktiviere, startet dieser nach ein paar Sekunden neu und im Log stehen die oben genannten Fehlermeldungen.
Die Log Meldungen wiederholt sich bei jedem Absturz und Neustart vom JS Adapter.
Dementsprechend habe ich für die Fehlermeldung den JS Adapter im Verdacht.
Ist der JS Adapter deaktiviert, kommt die Fehlermeldung nicht.
Support us
838
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge