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

[crunchip]

@christianf sagte in JS-Controller erzeugt nach 3.3.22 Update sehr hohe CPU Last:

nach dem Upgrade auf JS-Controller 3.3.22

welche Version lief zuvor?

@christianf sagte in JS-Controller erzeugt nach 3.3.22 Update sehr hohe CPU Last:

Das Log vom iobroker selsbt ist unauffällig, auch die Adapter

steht möglicherweise der ein oder andere Adapter auf Warnstufe error und siehst deshalb nichts

[falke69]

@christianf

Spoiler

Plattform linux
Betriebssystem linux
Architektur arm
CPUs 4
Geschwindigkeit 1800 MHz
Modell ARMv7 Processor rev 3 (v7l)
RAM 7.71 GB
System-Betriebszeit 00:34:49
Node.js v14.18.2
NPM 6.14.15
Datenträgergröße 109.73 GB
freier Festplattenspeicher 99.06 GB
Anzahl der Adapter 363
Betriebszeit 00:34:53
Aktive Instanzen 32
location /opt/iobroker/
Hostname iobroker

kann ich bestätigen. Ist bei mir auch so. Alle Adapter sind grün. Es geht sogar stellenweise bis 80% hoch.
Habe ich bisher noch nich verfolgt.

[Jan1]

Bei mir ist alle so wie vorher auch, deshalb war auch die Frage, ob die Auslastung konstant so hoch bleibt.

Tasks: 130 total,   1 running, 129 sleeping,   0 stopped,   0 zombie
%CPU(s): 10,9 us,  3,3 sy,  0,0 ni, 85,3 id,  0,0 wa,  0,0 hi,  0,5 si,  0,0 st
MiB Spch:   3758,9 total,    435,3 free,   2097,2 used,   1226,4 buff/cache
MiB Swap:   3928,0 total,   3927,7 free,      0,2 used.   1406,7 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
2672442 iobroker  20   0 1104944 279812  37728 S   9,3   7,3   1598:16 iobroker.js-con
2672490 iobroker  20   0  848828 177264  36444 S   4,0   4,6 531:05.79 io.javascript.0
2672788 iobroker  20   0  954528 107524  32316 S   3,6   2,8 575:25.76 io.info.0
2672629 iobroker  20   0  968112  98124  36652 S   1,7   2,5 149:58.92 io.tr-064.0
2395736 jan       20   0   10300   4068   3320 R   1,0   0,1   0:00.36 top
2672697 iobroker  20   0  595780  52808  30908 S   1,0   1,4 159:17.66 node
2672681 iobroker  20   0  651780  70068  31336 S   0,7   1,8  61:07.93 io.ble.0
 374316 iobroker  20   0 1020116 147288  36948 S   0,3   3,8  13:42.24 io.admin.0
1512684 iobroker  20   0  946628  83680  36884 S   0,3   2,2   0:55.84 io.telegram.0
2672475 iobroker  20   0  727996 103968  31336 S   0,3   2,7  14:36.03 io.history.0
2672758 iobroker  20   0  662824  81908  31888 S   0,3   2,1  38:47.50 io.fritzdect.0
2673161 iobroker  20   0  688096  70980  31336 S   0,3   1,8  12:48.67 io.iqontrol.0
2673581 iobroker  20   0  942252  83592  32408 S   0,3   2,2  16:47.79 io.tankerkoenig
2673769 iobroker  20   0  938316  81228  32432 S   0,3   2,1  22:22.47 io.vr200.0
2674306 iobroker  20   0  646992  64712  31192 S   0,3   1,7  13:24.12 io.samsung_tize
3055972 iobroker  20   0  674092  75864  31392 S   0,3   2,0  12:25.13 io.harmony.0
3910818 iobroker  20   0  956252  79292  32456 S   0,3   2,1   6:03.02 io.vw-connect.0
      1 root      20   0  165300  10664   7736 S   0,0   0,3   0:10.67 systemd

[falke69]

@jan1

ich habe jetzt mal die ganze Sache eine Weile beobachtet. Kurzzeitig mal bei ca. 60% - 70%
und kleinere Spitzen bis 80% und dann hauptsächlich zwischen 20% & 30%.

Für mich sieht das normal aus.

[Jan1]

@falke69
kommt drauf an auf welcher HW der IOBroker läuft. Mein Beelink ist nicht die flotteste Kiste und da sind 10% normal ;)

[falke69]

@jan1

ich habe einen P4 / 8GB.
Bisher auch keinerlei Probleme. :blush:

[ChristianF]

Danke für die schnellen Antworten. Ich versuche mal, das der Reihe nach zu beantworten.

• die Auslastung ist dauerhaft hoch. Meistens irgendwo zwischen 40-60%, in Peaks auch höher. Die VM ist inzwischen so ressourcenhungrig, dass sie andere Maschinen in der CPU Verfügbarkeit einschränkt und der Kühlungsaufwand des Hosts hochgeht. Das gab es vorher eindeutig nicht. Ich musste die VM deaktivieren, damit der Rest weiter läuft.
• iobroker läuft auf einer Debian Bullseye VM auf einem QNAP ts-253a NAS. Der VM sind 4 Cores und 2GB RAM zugewiesen. CPU zieht sie wie gesagt viel, beim RAM ist sie eher genügsam und kommt meistens mit unter 70% aus.

[Strobelix]

@christianf kann ähnliches berichten.
Bei mir hängt dann vis und auch die Datenpunkte für ca 10sek und dann läuft wieder alles normal.
Das wiederholt sich im 30-60sek Takt auch wenn alle Adapter aus sind

[Feuersturm]

@strobelix hast du auch deine Skripte einmal testweise deaktiviert?

[Strobelix]

@feuersturm macht das einen Unterschied, wenn der Javascript Adapter nich läuft?

[Feuersturm]

@strobelix Ok, dann sollten auch keine Skripte mehr laufen.

[ChristianF]

Ich habe auch noch mal ein bisschen Analyse betrieben und testweise den Info Adapter deaktiviert, den ich im Verdacht hatte. Keine Änderung. Mit einem versuchten Downgrade auf 3.3.19 habe ich mir dann erfolgreich die Installation zerschossen und durfte komplett neu anfangen. Ergebnis: exakt dasselbe.

[Strobelix]

@christianf
Ich bin auch auf js 3.3.19 dazu muss man dann auch den Admin downgraden.
Es ist jetzt anders aber nicht so wie vorher.
Ich habe immer noch das Problem, dass iobroker jede Minute für gut 10 Sekunden hängt.
Ich hoffe ich finde das Problem bald

[e-s]

@strobelix
Habe bei mir das Problem auch, bei mir hat der shelly Adapter generell 30-40% mehr gemacht. Den Fehler davon konnte ich schon eingrenzen.
Aber ich habe auch rhythmisch jede Minute 2 Peaks welche jeweils ca. 4 Sekunden andauern mit einer kurzen Pause dazwischen.
Da die grundlast durch den shelly so hoch war, kam ich auch auf volle auslastung. Ohne den Fehler habe ich zwischen 10 und 20% Ruhe und 80% in den Peaks.
Werde auch mal schauen ob ich noch etwas finden kann.

edit:
bei mir war fb-checkpresense das Problem, wenn der Adapter aus ist, dann habe ich keine Peaks mehr

[Strobelix]

@e-s habe den Übeltäter jetzt auch endlich gefunden. Liegt nicht am js-controller sondern am Fröling Connect Adapter. Der frägt in meinem Fall so viele Daten ab, das das System dann kurz hängt.