JS-Controller erzeugt nach 3.3.22 Update sehr hohe CPU Last
-
Hallo,
nach dem Upgrade auf JS-Controller 3.3.22 stelle ich auf meinem Haupt-iobroker Server fest, dass die CPU Last auf einmal sehr hoch geht. Bisher dümpelte der Server friedlich bei seinen max. 10-15% CPU Last rum, jetzt sind es dauerhaft zwischen 30% und 70%. Ein top zeigt, dass tatsächlich der JS-controller für die hohe CPU Last zuständig ist. Das Log vom iobroker selsbt ist unauffällig, auch die Adapter und Scripte laufen problemlos.
Unterbau ist ein Debian Bullseye, frisch gepatcht. Node.js ist v14.18.2 und NPM ist 6.14.15. Plattenplatz und RAM sind ausreichend vorhanden. Die Maschine ist nur für ioBroker.
Hat jemand eine Idee?
Danke und Viele Grüße
Christian
-
@christianf
Ist das dauerhaft so hoch oder nur kurz? -
@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
-
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. -
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 -
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.
-
@falke69
kommt drauf an auf welcher HW der IOBroker läuft. Mein Beelink ist nicht die flotteste Kiste und da sind 10% normal
-
ich habe einen P4 / 8GB.
Bisher auch keinerlei Probleme.
-
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.
-
@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 -
@strobelix hast du auch deine Skripte einmal testweise deaktiviert?
-
@feuersturm macht das einen Unterschied, wenn der Javascript Adapter nich läuft?
-
@strobelix Ok, dann sollten auch keine Skripte mehr laufen.
-
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.
-
@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 -
@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 -
@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.
