Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Skripten / Logik
    4. JavaScript
    5. controller.js frist Ram und javascript.X bei >90%

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    controller.js frist Ram und javascript.X bei >90%

    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tasuanetrukiat last edited by Homoran

      Hallo,

      ich nutze Iobroker im Container einer XEN Instanz mit 2 CPU und nun 16GiB Ram.

      Plattform: docker (official image - v10.0.0)
      RAM: 15.6 GB
      Node.js: v20.18.2(20.18.3)
      NPM: 10.8.2

      Das ist der Container auf den ich erst ich meine diesen Monat gewechselt bin.

      Trotzdem kommt es ab und an mal vor das der Hauptspeicher nicht ausreicht und der Kernel dann den Prozess mit dem meisten Speicher abschießt und danach iobroker nicht mehr reagiert, so das ich den docker-container neu starten muss.

      Im IOBroker log sieht das in den letzten Zeilen so aus:

      2025-02-19T12:52:34.494128327Z ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.l
      ogging]
      2025-02-19T15:26:11.230275656Z Send diag info: {"uuid":".....","language":"de","country":"Germany","hosts"
      :[{"version":"7.0.6","platform":"Javascript/Node.js","type":"linux"}],"node":"v20.18.2","arch":"x64","docker":true,"adapters":{"admin":{"
      version":"7.4.10","platform":"Javascript/Node.js","installedFrom":"iobroker.admin@7.4.10"},"backitup":{"version":"3.0.31","platform":"Jav
      ascript/Node.js","installedFrom":"iobroker.backitup@3.0.31"},"habpanel":{"version":"0.5.0","platform":"Javascript/Node.js","installedFrom
      ":"iobroker.habpanel@0.5.0"},"history":{"version":"3.0.1","platform":"Javascript/Node.js","installedFrom":"iobroker.history@3.0.1"},"java
      script":{"version":"8.8.3","platform":"Javascript/Node.js","installedFrom":"iobroker.javascript@8.8.3"},"mielecloudservice":{"version":"6
      .5.7","platform":"Javascript/Node.js","installedFrom":"iobroker.mielecloudservice@6.5.7"},"modbus":{"version":"6.3.2","platform":"Javascr
      ipt/Node.js","installedFrom":"iobroker.modbus@6.3.2"},"mqtt":{"version":"6.1.2","platform":"Javascript/Node.js","installedFrom":"iobroker
      .mqtt@6.1.2"},"radar2":{"version":"2.2.0","platform":"Javascript/Node.js","installedFrom":"iobroker.radar2@2.2.0"},"valuetrackerovertime"
      :{"version":"1.1.0","platform":"Javascript/Node.js","installedFrom":"iobroker.valuetrackerovertime@1.1.0"},"web":{"version":"6.2.5","plat
      form":"Javascript/Node.js","installedFrom":"iobroker.web@6.2.5"},"ws":{"version":"2.6.2","platform":"Javascript/Node.js","installedFrom":
      "iobroker.ws@2.6.2"},"socketio":{"version":"6.7.1","platform":"Javascript/Node.js","installedFrom":"iobroker.socketio@6.7.1"},"signal-cmb
      ":{"version":"0.3.0","platform":"Javascript/Node.js","installedFrom":"iobroker.signal-cmb@0.3.0"},"roborock":{"version":"0.6.18","platfor
      m":"Javascript/Node.js","installedFrom":"iobroker.roborock@0.6.18"}},"statesType":"jsonl","objectsType":"jsonl","noInstances":17,"compact
      Mode":false,"noCompactInstances":0,"model":"AMD EPYC 7251 8-Core Processor","cpus":2,"mem":16770875392,"ostype":"Linux","city":"..."}
      2025-02-19T22:35:41.323286729Z /opt/scripts/iobroker_startup.sh: line 591:   135 Killed                  gosu iobroker node node_modules/
      iobroker.js-controller/controller.js
      

      MOD-EDIT: private Daten entfernt!
      dmesg zeigt hier:

      [Wed, 19. Feb 2025, 21:35:11] containerd invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=-999
      [Wed, 19. Feb 2025, 21:35:11] CPU: 0 PID: 650 Comm: containerd Tainted: G        W          6.1.0-29-amd64 #1  Debian 6.1.123-1
      [Wed, 19. Feb 2025, 21:35:11] Call Trace:
      [Wed, 19. Feb 2025, 21:35:11]  <TASK>
      [Wed, 19. Feb 2025, 21:35:11]  dump_stack_lvl+0x44/0x5c
      [Wed, 19. Feb 2025, 21:35:11]  dump_header+0x4a/0x211
      [Wed, 19. Feb 2025, 21:35:11]  oom_kill_process.cold+0xb/0x10
      [Wed, 19. Feb 2025, 21:35:11]  out_of_memory+0x1fd/0x4c0
      [Wed, 19. Feb 2025, 21:35:11]  __alloc_pages_slowpath.constprop.0+0xc83/0xe40
      [Wed, 19. Feb 2025, 21:35:11]  ? __alloc_pages_slowpath.constprop.0+0xd17/0xe40
      [Wed, 19. Feb 2025, 21:35:11]  __alloc_pages+0x305/0x330
      [Wed, 19. Feb 2025, 21:35:11]  folio_alloc+0x17/0x50
      [Wed, 19. Feb 2025, 21:35:11]  __filemap_get_folio+0x155/0x340
      [Wed, 19. Feb 2025, 21:35:11]  filemap_fault+0x139/0x910
      [Wed, 19. Feb 2025, 21:35:11]  ? filemap_map_pages+0x153/0x700
      [Wed, 19. Feb 2025, 21:35:11]  __do_fault+0x33/0x110
      [Wed, 19. Feb 2025, 21:35:11]  do_fault+0x1b9/0x410
      [Wed, 19. Feb 2025, 21:35:11]  __handle_mm_fault+0x660/0xfa0
      [Wed, 19. Feb 2025, 21:35:11]  ? __rseq_handle_notify_resume+0xa9/0x4a0
      [Wed, 19. Feb 2025, 21:35:11]  handle_mm_fault+0xdb/0x2d0
      [Wed, 19. Feb 2025, 21:35:11]  do_user_addr_fault+0x191/0x550
      [Wed, 19. Feb 2025, 21:35:11]  exc_page_fault+0x70/0x170
      [Wed, 19. Feb 2025, 21:35:11]  asm_exc_page_fault+0x22/0x30
      [Wed, 19. Feb 2025, 21:35:11] RIP: 0033:0xcd2c9d
      [Wed, 19. Feb 2025, 21:35:11] Code: Unable to access opcode bytes at 0xcd2c73.
      [Wed, 19. Feb 2025, 21:35:11] RSP: 002b:00007f27def84d98 EFLAGS: 00010212
      [Wed, 19. Feb 2025, 21:35:11] RAX: 0000000000000000 RBX: 0000000000002710 RCX: 0000000000cd2c9d
      [Wed, 19. Feb 2025, 21:35:11] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007f27def84d98
      [Wed, 19. Feb 2025, 21:35:11] RBP: 00007f27def84da8 R08: 00000000016bc801 R09: 00000000000000e9
      [Wed, 19. Feb 2025, 21:35:11] R10: 0000000000000000 R11: 0000000000000212 R12: 00007f27def847d8
      [Wed, 19. Feb 2025, 21:35:11] R13: 0000000000000016 R14: 000000c0000069c0 R15: 00007f27de785000
      [Wed, 19. Feb 2025, 21:35:11]  </TASK>
      [Wed, 19. Feb 2025, 21:35:11] Mem-Info:
      [Wed, 19. Feb 2025, 21:35:11] active_anon:428472 inactive_anon:3553781 isolated_anon:0
                                     active_file:25 inactive_file:417 isolated_file:0
                                     unevictable:0 dirty:0 writeback:0
                                     slab_reclaimable:10607 slab_unreclaimable:10658
                                     mapped:3 shmem:56 pagetables:25205
                                     sec_pagetables:0 bounce:0
                                     kernel_misc_reclaimable:0
                                     free:23572 free_pcp:111 free_cma:0
      [Wed, 19. Feb 2025, 21:35:11] Node 0 active_anon:1713888kB inactive_anon:14215124kB active_file:100kB inactive_file:1668kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:12kB dirty:0kB writeback:0kB shmem:224kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB kernel_stack:6272kB pagetables:100820kB sec_pagetables:0kB all_unreclaimable? yes
      [Wed, 19. Feb 2025, 21:35:11] Node 0 DMA free:13888kB boost:0kB min:12kB low:24kB high:36kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15996kB managed:15936kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
      [Wed, 19. Feb 2025, 21:35:11] lowmem_reserve[]: 0 3902 15845 15845 15845
      [Wed, 19. Feb 2025, 21:35:11] Node 0 DMA32 free:53728kB boost:0kB min:3964kB low:7960kB high:11956kB reserved_highatomic:0KB active_anon:96360kB inactive_anon:3939364kB active_file:0kB inactive_file:496kB unevictable:0kB writepending:0kB present:4177920kB managed:4132472kB mlocked:0kB bounce:0kB free_pcp:308kB local_pcp:60kB free_cma:0kB
      [Wed, 19. Feb 2025, 21:35:11] lowmem_reserve[]: 0 0 11942 11942 11942
      [Wed, 19. Feb 2025, 21:35:11] Node 0 Normal free:26672kB boost:0kB min:12136kB low:24364kB high:36592kB reserved_highatomic:14336KB active_anon:1617528kB inactive_anon:10275760kB active_file:100kB inactive_file:1184kB unevictable:0kB writepending:0kB present:12582912kB managed:12229400kB mlocked:0kB bounce:0kB free_pcp:136kB local_pcp:12kB free_cma:0kB
      [Wed, 19. Feb 2025, 21:35:11] lowmem_reserve[]: 0 0 0 0 0
      [Wed, 19. Feb 2025, 21:35:11] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 1*64kB (U) 2*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 2*2048kB (UM) 2*4096kB (M) = 13888kB
      [Wed, 19. Feb 2025, 21:35:11] Node 0 DMA32: 206*4kB (UME) 449*8kB (UME) 478*16kB (UME) 68*32kB (UME) 49*64kB (ME) 56*128kB (UME) 42*256kB (UME) 14*512kB (UME) 9*1024kB (UME) 1*2048kB (M) 0*4096kB = 53728kB
      [Wed, 19. Feb 2025, 21:35:11] Node 0 Normal: 766*4kB (UME) 705*8kB (UME) 281*16kB (UME) 157*32kB (UME) 96*64kB (UME) 18*128kB (UM) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 26672kB
      [Wed, 19. Feb 2025, 21:35:11] 29352 total pagecache pages
      [Wed, 19. Feb 2025, 21:35:11] 28848 pages in swap cache
      [Wed, 19. Feb 2025, 21:35:11] Free swap  = 0kB
      [Wed, 19. Feb 2025, 21:35:11] Total swap = 4194300kB
      [Wed, 19. Feb 2025, 21:35:11] 4194207 pages RAM
      [Wed, 19. Feb 2025, 21:35:11] 0 pages HighMem/MovableOnly
      [Wed, 19. Feb 2025, 21:35:11] 99755 pages reserved
      [Wed, 19. Feb 2025, 21:35:11] 0 pages hwpoisoned
      [Wed, 19. Feb 2025, 21:35:11] Tasks state (memory values in pages):
      [Wed, 19. Feb 2025, 21:35:11] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
      [Wed, 19. Feb 2025, 21:35:11] [    203]     0   203    36907      108   319488      181          -250 systemd-journal
      [Wed, 19. Feb 2025, 21:35:11] [    227]     0   227     6567       94    73728      195         -1000 systemd-udevd
      [Wed, 19. Feb 2025, 21:35:11] [    360]     0   360      900       23    53248       36             0 cron
      [Wed, 19. Feb 2025, 21:35:11] [    361]   103   361     2042      106    53248       62          -900 dbus-daemon
      [Wed, 19. Feb 2025, 21:35:11] [    363]     0   363     4250      137    77824      202             0 systemd-logind
      [Wed, 19. Feb 2025, 21:35:11] [    389]     0   389    28168        0   110592     2354             0 unattended-upgr
      [Wed, 19. Feb 2025, 21:35:11] [    390]     0   390     1865        0    53248       33             0 agetty
      [Wed, 19. Feb 2025, 21:35:11] [    391]     0   391      629        0    40960       31             0 agetty
      [Wed, 19. Feb 2025, 21:35:11] [    393]     0   393   338305     2955   303104      419          -999 containerd
      [Wed, 19. Feb 2025, 21:35:11] [    644]     0   644     5656        7    65536      291             0 bacula-fd
      [Wed, 19. Feb 2025, 21:35:11] [    668]     0   668   383555     6065   421888     1571             0 dockerd
      [Wed, 19. Feb 2025, 21:35:11] [    818]     0   818     4385        6    77824      457             0 sshd
      [Wed, 19. Feb 2025, 21:35:11] [    821]     0   821     4745      166    81920      271           100 systemd
      [Wed, 19. Feb 2025, 21:35:11] [    822]     0   822    25675       14    94208      723           100 (sd-pam)
      [Wed, 19. Feb 2025, 21:35:11] [    842]     0   842     1047       49    45056       86             0 bash
      [Wed, 19. Feb 2025, 21:35:11] [ 117355]     0 117355     5975     1261    86016     2735             0 screen
      [Wed, 19. Feb 2025, 21:35:11] [ 117713]     0 117713     2223       93    53248       70             0 bash
      [Wed, 19. Feb 2025, 21:35:11] [ 252983]     0 252983     4625      294    77824      379             0 sshd
      [Wed, 19. Feb 2025, 21:35:11] [ 252990]     0 252990     2196        2    57344      145             0 bash
      [Wed, 19. Feb 2025, 21:35:11] [ 253018]     0 253018     2079       14    61440       51             0 screen
      [Wed, 19. Feb 2025, 21:35:11] [1257177]   997 1257177    22521      233    81920        0             0 systemd-timesyn
      [Wed, 19. Feb 2025, 21:35:11] [1257501]   102 1257501     7643     3149   102400      143             0 exim4
      [Wed, 19. Feb 2025, 21:35:11] [1838410]     0 1838410     2196      146    57344        3             0 bash
      [Wed, 19. Feb 2025, 21:35:11] [2085871]     0 2085871     3859      278    69632       31         -1000 sshd
      [Wed, 19. Feb 2025, 21:35:11] [2122942]     0 2122942   270622        0   126976      153             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2122948]     0 2122948   270622        0   122880      154             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2122960]     0 2122960   270622        0   126976      152             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2122965]     0 2122965   270622        0   126976      155             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2122978]     0 2122978   289055        0   139264      158             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2122984]     0 2122984   289055       20   135168      123             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2122998]     0 2122998   270622      143   122880        0             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123003]     0 2123003   289055      145   139264        0             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123017]     0 2123017   289055      144   135168        1             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123023]     0 2123023   270622      142   131072        3             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123036]     0 2123036   307552      147   143360        0             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123043]     0 2123043   270622      145   126976        0             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123056]     0 2123056   270622      144   131072        0             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123062]     0 2123062   289055      144   139264        0             0 docker-proxy
      [Wed, 19. Feb 2025, 21:35:11] [2123076]     0 2123076   365896      801   208896       79          -998 containerd-shim
      [Wed, 19. Feb 2025, 21:35:11] [2123097]     0 2123097     1853        2    49152       85             0 bash
      [Wed, 19. Feb 2025, 21:35:11] [2123192]     0 2123192     2196      113    57344       15             0 bash
      [Wed, 19. Feb 2025, 21:35:11] [2123233]     0 2123233   300196     2436   249856       78             0 docker
      [Wed, 19. Feb 2025, 21:35:11] [2123284]  1000 2123284 10209663  3686161 66260992   967566             0 iobroker.js-con
      [Wed, 19. Feb 2025, 21:35:12] [2123327]  1000 2123327  5595933    19876  3260416    11995             0 io.admin.0
      [Wed, 19. Feb 2025, 21:35:12] [2123351]  1000 2123351  5529054    11181  2080768     3453             0 io.history.0
      [Wed, 19. Feb 2025, 21:35:12] [2123379]  1000 2123379  5611435    31899  5578752    11485             0 io.javascript.0
      [Wed, 19. Feb 2025, 21:35:12] [2123394]  1000 2123394  5585875    60205  7409664    11914             0 io.javascript.1
      [Wed, 19. Feb 2025, 21:35:12] [2123430]  1000 2123430  5507315     8901  1826816     3302             0 io.backitup.0
      [Wed, 19. Feb 2025, 21:35:12] [2123441]  1000 2123441  5556326     9770  1851392     2709             0 io.mielecloudse
      [Wed, 19. Feb 2025, 21:35:12] [2123460]  1000 2123460  5506277     8775  1675264     1603             0 io.modbus.0
      [Wed, 19. Feb 2025, 21:35:12] [2123475]  1000 2123475  5577396    15225  2113536     1725             0 io.modbus.1
      [Wed, 19. Feb 2025, 21:35:12] [2123512]  1000 2123512  5505270     7526  1544192     2113             0 io.modbus.2
      [Wed, 19. Feb 2025, 21:35:12] [2123527]  1000 2123527  5507894    11715  1912832     1892             0 io.mqtt.0
      [Wed, 19. Feb 2025, 21:35:12] [2123542]  1000 2123542  5524024    10346  1933312     2459             0 io.mqtt.1
      [Wed, 19. Feb 2025, 21:35:12] [2123557]  1000 2123557  5571896     9431  1777664     4545             0 io.radar2.0
      [Wed, 19. Feb 2025, 21:35:12] [2123615]  1000 2123615  5515364    12391  2531328     2748             0 io.valuetracker
      [Wed, 19. Feb 2025, 21:35:12] [2123630]  1000 2123630  5551156    20954  1794048     4843             0 io.web.0
      [Wed, 19. Feb 2025, 21:35:12] [2123645]  1000 2123645  5570328     7619  1486848     2499             0 io.signal-cmb.0
      [Wed, 19. Feb 2025, 21:35:12] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=containerd.service,mems_allowed=0,global_oom,task_memcg=/system.slice/docker-9ceeb57b1a9d677c89577249e7dad789ff530af1a24f68d21e7cbe403667449c.scope,task=iobroker.js-con,pid=2123284,uid=1000
      [Wed, 19. Feb 2025, 21:35:12] Out of memory: Killed process 2123284 (iobroker.js-con) total-vm:40838652kB, anon-rss:14744644kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:64708kB oom_score_adj:0
      [Wed, 19. Feb 2025, 21:35:15] oom_reaper: reaped process 2123284 (iobroker.js-con), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
      [
      

      Ich hatte das Problem auch schon mal früher bevor ich eine 2. javascript instanz installiert habe und die Skripte auf beide Instanzen aufgeteilt habe. Davor war die einzelne Instanz immer bei 100 % CPU und danach hat es sich auf < 5 % CPU bei beiden Prozessen beruhigt. Auch das Abschießen des Prozesses hatte ich dann nicht mehr gesehen.

      Jetzt sind beide Prozesse bei nahe 100 % CPU was vermutlich an mehr Skripten liegt:

      top - 10:35:59 up 34 days, 16:41,  4 users,  load average: 2.77, 2.86, 2.45
      Tasks: 117 total,   4 running, 113 sleeping,   0 stopped,   0 zombie
      %CPU(s): 88.3 us, 11.0 sy,  0.0 ni,  0.5 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st 
      MiB Spch:  15994.0 total,   8298.2 free,   2225.6 used,   5643.2 buff/cache     
      MiB Swap:   4096.0 total,   4054.3 free,     41.7 used.  13768.4 avail Spch
      
          PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                           
      2235915 1000      20   0   21.8g 719788  45156 S   1.3   4.4   4:59.10 iobroker.js-con                                                  
      2236004 1000      20   0   21.4g 241672  43720 R  96.0   1.5  17:30.73 io.javascript.0                                                  
      2236025 1000      20   0   21.2g 238568  43984 R  98.3   1.5  17:29.56 io.javascript.1                                                  
      2235936 1000      20   0   21.3g 178496  50348 S   0.0   1.1   0:22.66 io.admin.0                                                       
      2236040 1000      20   0   21.3g 157208  49708 S   0.0   1.0   1:30.08 io.backitup.0                                                    
      2236265 1000      20   0   21.2g 124408  45148 S   0.0   0.8   0:04.68 io.web.0                                                         
      2235974 1000      20   0   21.1g  99760  43468 S   0.3   0.6   0:47.56 io.history.0                                                     
      2236229 1000      20   0   21.0g  94408  43544 S   0.0   0.6   2:53.40 io.valuetracker                                                  
      2236162 1000      20   0   21.0g  92300  43556 S   0.3   0.6   0:13.21 io.mqtt.0
      

      Hier kann man noch die gefühlt eher normalen Speichernutzung sehen.

      Ist es möglich das es in solchen Situationen mit einer dauerhaft hohen CPU Last der Javaskript Kram dazu tendiert den Speicher aufzufressen?

      Was mich auch wundert ist das beide Javascript-Prozesse hier viel CPU-Last generieren. Ich hatte eher damit gerechnet das nur einer solche Probleme macht.

      Wenn ich alle Skripte stoppe dann sinkt auch die CPU Last nicht sehr sondern bleibt auf hoher Nutzung bis ich den Docker-Container neu starte.

      Was mir aber gerade aufgefallen ist: Im Instanzscreen werden beide Prozesse immer wieder rot:
      155a72e0-adbb-4843-980b-bb4493cdd704-grafik.png

      Allerdings scheint auch nun das neustarten des Containers nicht weiter zu helfen.

      Was mir aber aufgefallen ist, wenn ich den valuetrackerovertime abschalte scheinen sich auch beide Prozesse zu beruhigen.
      Daher gehe ich davon aus das der Ursprung meiner Probleme eigentlich irgendwo hier liegt. Aber es wundert mich das hier dann nicht der valuetracker-Prozess wild wird.

      Hat jemand eine Idee wie ich hier weiter komme? Ich würde ungern auf den valuetracker… verzichten wollen.

      T paul53 2 Replies Last reply Reply Quote 0
      • T
        tasuanetrukiat @tasuanetrukiat last edited by

        Es scheint tatsächlich irgendwie mit dem valuetracker zusammen zu hängen. Ich habe nun erst mal alle Überwachten Objekte abgeschaltet. Mit max. 30 Stück fand ich das eigentlich nicht so viele. Aber nun haben sich die CPU Werte ohne gestartete java-Skripte auf > 1% eingependelt.

        Hat jemand eine Idee wann wann der valuetracker anfängt so rum zu spinnen?

        1 Reply Last reply Reply Quote 0
        • paul53
          paul53 @tasuanetrukiat last edited by

          @tasuanetrukiat sagte: beide Javascript-Prozesse hier viel CPU-Last generieren.

          Gibt es Skripte in der Gruppe "global" (Expertenmodus)?

          T 1 Reply Last reply Reply Quote 0
          • T
            tasuanetrukiat @paul53 last edited by

            @paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

            @tasuanetrukiat sagte: beide Javascript-Prozesse hier viel CPU-Last generieren.

            Gibt es Skripte in der Gruppe "global" (Expertenmodus)?
            Also ich habe da nie rum gefummelt und nie den Expertenmodus verwendet.

            paul53 1 Reply Last reply Reply Quote 0
            • paul53
              paul53 @tasuanetrukiat last edited by

              @tasuanetrukiat sagte: da nie rum gefummelt und nie den Expertenmodus verwendet.

              Vielleicht hat der Adapter "valuetracker" Skripte unter "global" erstellt?

              T 1 Reply Last reply Reply Quote 0
              • T
                tasuanetrukiat @paul53 last edited by

                @paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

                @tasuanetrukiat sagte: da nie rum gefummelt und nie den Expertenmodus verwendet.

                Vielleicht hat der Adapter "valuetracker" Skripte unter "global" erstellt?
                Sieht nicht so aus:
                95c7c16b-abe1-4199-90b5-df89fd273562-grafik.png

                paul53 1 Reply Last reply Reply Quote 0
                • BananaJoe
                  BananaJoe Most Active last edited by BananaJoe

                  @tasuanetrukiat sagte in controller.js frist Ram und javascript.X bei >90%:

                  Was mich auch wundert ist das beide Javascript-Prozesse hier viel CPU-Last generieren. Ich hatte eher damit gerechnet das nur einer solche Probleme macht.
                  Wenn ich alle Skripte stoppe dann sinkt auch die CPU Last nicht sehr sondern bleibt auf hoher Nutzung bis ich den Docker-Container neu starte.
                  Was mir aber gerade aufgefallen ist: Im Instanzscreen werden beide Prozesse immer wieder rot:

                  Ich würde stark vermuten das du Amok-Laufende Skripte hast.
                  Beispielsweise ein Skript welches viele oder sogar endlos neue Trigger erzeugt - und dann statt wie geplant 1 Trigger dann gleich 50 anspringen die alle das gleiche machen.

                  Was für eine CPU steckt in deinem XEN-Server Host?

                  valuetrackerovertime ist ein eigener Adapter und sollte somit getrennt in der CPU-Auslastung auftauchen. Und keine Wechselwirkung mit den JavaSkript-Adapter-Instanzen haben. Außer wenn du mit Skripten darauf reagierst

                  T 1 Reply Last reply Reply Quote 0
                  • T
                    tasuanetrukiat @BananaJoe last edited by

                    @bananajoe sagte in controller.js frist Ram und javascript.X bei >90%:

                    @tasuanetrukiat sagte in controller.js frist Ram und javascript.X bei >90%:

                    Was mich auch wundert ist das beide Javascript-Prozesse hier viel CPU-Last generieren. Ich hatte eher damit gerechnet das nur einer solche Probleme macht.
                    Wenn ich alle Skripte stoppe dann sinkt auch die CPU Last nicht sehr sondern bleibt auf hoher Nutzung bis ich den Docker-Container neu starte.
                    Was mir aber gerade aufgefallen ist: Im Instanzscreen werden beide Prozesse immer wieder rot:

                    Ich würde stark vermuten das du Amok-Laufende Skripte hast.
                    Beispielsweise ein Skript welches viele oder sogar endlos neue Trigger erzeugt - und dann statt wie geplant 1 Trigger dann gleich 50 anspringen die alle das gleiche machen.

                    Was für eine CPU steckt in deinem XEN-Server Host?

                    Steht oben im iobroker log:

                    "model":"AMD EPYC 7251 8-Core Processor"
                    

                    Sollte eigentlich nicht sein. Vor allem wenn ich gar keine Skripte starte sollte die CPU nicht bei nahe 100 % arbeiten, oder?

                    paul53 1 Reply Last reply Reply Quote 0
                    • paul53
                      paul53 @tasuanetrukiat last edited by

                      @tasuanetrukiat sagte: Sieht nicht so aus:

                      Dann vermute ich, dass du Skripte hast, die Amok laufen, sobald sie auf Datenpunkte von "valuetracker" zugreifen / triggern.

                      T 1 Reply Last reply Reply Quote 0
                      • T
                        tasuanetrukiat @paul53 last edited by

                        @paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

                        @tasuanetrukiat sagte: Sieht nicht so aus:

                        Dann vermute ich, dass du Skripte hast, die Amok laufen, sobald sie auf Datenpunkte von "valuetracker" zugreifen / triggern.

                        Ja, ich habe wohl das eine oder andere Skript das mal auf einen Wert vom valuetracker zugreift. Aber wenn das skript gar nicht gestartet wird, sollte es dann doch auch nicht wild laufen, oder?

                        1 Reply Last reply Reply Quote 0
                        • paul53
                          paul53 @tasuanetrukiat last edited by

                          @tasuanetrukiat sagte: wenn ich gar keine Skripte starte sollte die CPU nicht bei nahe 100 % arbeiten, oder?

                          Nachdem alle Skripte gestoppt wurden, kann es sehr lange dauern, bis alle gepufferten Ereignisse abgearbeitet sind. Da hilft nur ein anschließender Neustart von ioBroker.

                          T 1 Reply Last reply Reply Quote 0
                          • T
                            tasuanetrukiat @paul53 last edited by

                            @paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

                            @tasuanetrukiat sagte: wenn ich gar keine Skripte starte sollte die CPU nicht bei nahe 100 % arbeiten, oder?

                            Nachdem alle Skripte gestoppt wurden, kann es sehr lange dauern, bis alle gepufferten Ereignisse abgearbeitet sind. Da hilft nur ein anschließender Neustart von ioBroker.

                            Das hatte ja trotz gestoppter Skripte auch nicht geholfen. Erst das stoppen des valuetracker hat gezeigt das es irgendwo damit zusammen hängt.
                            Dann hatte ich alle getrackten Werte im VT abgeschaltet und den VT selber wieder eingeschaltet und bisher sind auch keine hohen Werte zu beobachten.

                            T 1 Reply Last reply Reply Quote 0
                            • T
                              tasuanetrukiat @tasuanetrukiat last edited by

                              Aber das mit einem Trigger den ich immer wieder starte kann tatsächlich noch zusätzlich sein, da ich das mit den Blockly Skripten noch nicht vollständig verstanden habe.

                              Da sollte ich aber einen eigenen Tröt für machen.

                              Codierknecht 1 Reply Last reply Reply Quote 0
                              • Codierknecht
                                Codierknecht Developer Most Active @tasuanetrukiat last edited by

                                @tasuanetrukiat sagte in controller.js frist Ram und javascript.X bei >90%:

                                da ich das mit den Blockly Skripten noch nicht vollständig verstanden habe

                                Lesestoff: https://forum.iobroker.net/topic/70481/blockly-for-dummies-starthilfe-und-tipps

                                Ganz wichtig: "Trigger in Trigger" - nicht machen, niemals, never ever!

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Support us

                                ioBroker
                                Community Adapters
                                Donate

                                804
                                Online

                                31.8k
                                Users

                                80.0k
                                Topics

                                1.3m
                                Posts

                                4
                                14
                                445
                                Loading More Posts
                                • Oldest to Newest
                                • Newest to Oldest
                                • Most Votes
                                Reply
                                • Reply as topic
                                Log in to reply
                                Community
                                Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                                The ioBroker Community 2014-2023
                                logo