SQL-Adapter verursacht hohe CPU-Last
-
@Nashra Ja, genau, 3.1.4. Du hast nicht zufällig einen Link zur Anleitung wie man downgradet oder gar die benutzen Befehle? Ich muss doch zuerst 3.1.4 deinstallieren oder geht das downgraden auch direkt mittels npm install iobroker.js-controller@2.2.9 --production?
Danke!
-
@Urs sagte in SQL-Adapter verursacht hohe CPU-Last:
direkt mittelsnpm install iobroker.js-controller@2.2.9Vorher ioBroker stoppen, Backup und den Befehl im ioBroker-Verzeichnis ausführen (/opt/iobroker auf Linux).
-
@AlCalzone
Danke.
Werde aber noch zuwarten mit downgraden, denn im Moment läuft es mit knapp 10% CPU-Last, aber gut zu wissen wie es geht falls es dann doch nötig ist.Die im obigen Screenshot gezeigten Adapter hab ich entweder gelöscht weil sie nur zum testen waren (iquontrol, exchange rates und unify) oder nacheinander upgedated (ohne Auffälligkeiten). Bis auf einen, den Vodafone Speedcheck. Da bin ich mir noch nicht sicher ob ich den oder eher den web speedy nehmen soll, muss ich bei Gelegenheit nochmal testen.
Aber durch die ganze Testerei hab ich jetzt verschiedene hässliche Meldungen vom SQL Adapter bzw von MariaDB:
sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for web-speedy.0.Results.server.ping sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for web-speedy.0.Results.speeds.upload_MB sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for web-speedy.0.Results.speeds.download_Mb sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for web-speedy.0.Results.speeds.download_MB sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.ping.packetLoss sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.ping.avg sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.ping.max sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.ping.min sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.upload_Mb sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.upload_MB sql.0 2020-06-04 03:59:59.727 warn (3939) No realID found for vodafone-speedtest.0.Results.download_MBWie bekomme ich die am bessten weg?
-
Moin,
ich habe/hatte das Problem auch. Der SQL Adapter beanspruchte teils 80% der CPU, echt krass.
Heute morgen habe ich ein Update auf den JS-Controller 3.1.5 und ich wer erstaut wie die CPU Last abgenommen hat. Der SQL Adapter ist jetzt noch bei ca. 3% Last
Also alle mit Problemen, updaten des JS-Controllers und gucken. Ich bin gespannt ob Ihr das bestätigen könnt.
-
Moin, hatte die Tage ja wieder die 2.2.9 installiert womit es etwas ruhiger war
d.h. statt 60-80% waren es nur noch 40-50% CPU. Habe eben den die Neue
3.1.5 draufgehauen, mal sehen wie es jetzt läuft. Werde berichten. -
Hallo,
Hab den JS-Controller jetz auch auf 3.1.5 hochgezogen. Keine Ahnung was dabei schief gelaufen ist aber ich hatte etliche Fehler von einigen Adaptern, so im Stil:
gree_aircon.0 2020-06-07 00:53:52.603 warn (1358) This object will not be created in future versions. Please report this to the developer. gree_aircon.0 2020-06-07 00:53:52.603 warn (1358) Object gree_aircon.0.mode is invalid: obj.common.type has an invalid value (text) but has to be one of number, string, boolean, array, object, mixed, file, jsonDie konnte ich alle wieder hinbiegen, nur einer noch nicht:
node-red.0 2020-06-07 13:42:11.267 info (933) node-red exited with 6 node-red.0 2020-06-07 13:42:10.757 warn (19769) Terminated (UNCAUGHT_EXCEPTION): Without reason node-red.0 2020-06-07 13:42:09.756 error at processTicksAndRejections (internal/process/task_queues.js:97:5) node-red.0 2020-06-07 13:42:09.756 error at runMicrotasks (<anonymous>) node-red.0 2020-06-07 13:42:09.756 error at /opt/iobroker/iobroker-data/node-red/node_modules/huejay/lib/Transport.js:106:15 node-red.0 2020-06-07 13:42:09.756 error (19769) Error: Huejay: read ECONNRESET node-red.0 2020-06-07 13:42:09.755 error (19769) unhandled promise rejection: Huejay: read ECONNRESET Unhandled 2020-06-07 13:42:09.753 error promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().Von der Auslastung her kann es sein dass er jetzt etwas tiefer ist als vorher (bevor die extremen Auslastungen kamen), das kann ich nicht so genau sagen da ich daneben auch noch alle nicht benötigten Adapter rausgeschmissen habe. Mein NUC nuckelte jetzt die letzten paar Stunden knapp unter 10W / h, was für einen Server wo nebst Iobroker mit fast 30 Adaptern auch noch ein Pihole, eine Datenbank und noch weitere Dienste laufen nicht so schlecht ist. Prozessorauslastung bei 2-7%, alle ca 30 Sekunden kurz 15%. damit kann ich leben.
Das ursprüngliche Problem ist aber nicht gelöst, aber ich konnte die Verursacher etwas weiter eingrenzen. Sobald ich entweder den Vodafone Speedtest oder den Webspeedy aktiviere und davon Daten in die DB schreibe (4-8 Datenpunkte) geht die Auslastung durch die Decke. 30-50% dauerhaft. Stoppe ich z.B. den zuvor gestarteten Webspeedy bleibt die Auslastung bei 30% (der NUC saugt dann satte 25 W). Erst ein Neustart des SQL-Adapters bringt die Auslastung wieder runter. Wäre eine nette Spielerei gewesen die entsprechenden Internet-Geschwindigkeiten aufzuzeichnen, aber so wichtig ist es auch nicht. Hab die beiden jetzt runtergeschmissen und gut ist.
@AxelF1977 Welche Datenpunkte wertest Du bei den von Dir rot eingekreisten Graphs aus?
Hast du es schon versucht Temperaturen aus dem Proxmox zu bekommen und auszuwerten?
Danke und Gruss
Urs -
@Urs sagte in SQL-Adapter verursacht hohe CPU-Last:
Hallo,
Hab den JS-Controller jetz auch auf 3.1.5 hochgezogen. Keine Ahnung was dabei schief gelaufen ist aber ich hatte etliche Fehler von einigen Adaptern, so im Stil:
gree_aircon.0 2020-06-07 00:53:52.603 warn (1358) This object will not be created in future versions. Please report this to the developer. gree_aircon.0 2020-06-07 00:53:52.603 warn (1358) Object gree_aircon.0.mode is invalid: obj.common.type has an invalid value (text) but has to be one of number, string, boolean, array, object, mixed, file, jsonDie konnte ich alle wieder hinbiegen, nur einer noch nicht:
node-red.0 2020-06-07 13:42:11.267 info (933) node-red exited with 6 node-red.0 2020-06-07 13:42:10.757 warn (19769) Terminated (UNCAUGHT_EXCEPTION): Without reason node-red.0 2020-06-07 13:42:09.756 error at processTicksAndRejections (internal/process/task_queues.js:97:5) node-red.0 2020-06-07 13:42:09.756 error at runMicrotasks (<anonymous>) node-red.0 2020-06-07 13:42:09.756 error at /opt/iobroker/iobroker-data/node-red/node_modules/huejay/lib/Transport.js:106:15 node-red.0 2020-06-07 13:42:09.756 error (19769) Error: Huejay: read ECONNRESET node-red.0 2020-06-07 13:42:09.755 error (19769) unhandled promise rejection: Huejay: read ECONNRESET Unhandled 2020-06-07 13:42:09.753 error promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().Von der Auslastung her kann es sein dass er jetzt etwas tiefer ist als vorher (bevor die extremen Auslastungen kamen), das kann ich nicht so genau sagen da ich daneben auch noch alle nicht benötigten Adapter rausgeschmissen habe. Mein NUC nuckelte jetzt die letzten paar Stunden knapp unter 10W / h, was für einen Server wo nebst Iobroker mit fast 30 Adaptern auch noch ein Pihole, eine Datenbank und noch weitere Dienste laufen nicht so schlecht ist. Prozessorauslastung bei 2-7%, alle ca 30 Sekunden kurz 15%. damit kann ich leben.
Das ursprüngliche Problem ist aber nicht gelöst, aber ich konnte die Verursacher etwas weiter eingrenzen. Sobald ich entweder den Vodafone Speedtest oder den Webspeedy aktiviere und davon Daten in die DB schreibe (4-8 Datenpunkte) geht die Auslastung durch die Decke. 30-50% dauerhaft. Stoppe ich z.B. den zuvor gestarteten Webspeedy bleibt die Auslastung bei 30% (der NUC saugt dann satte 25 W). Erst ein Neustart des SQL-Adapters bringt die Auslastung wieder runter. Wäre eine nette Spielerei gewesen die entsprechenden Internet-Geschwindigkeiten aufzuzeichnen, aber so wichtig ist es auch nicht. Hab die beiden jetzt runtergeschmissen und gut ist.
@AxelF1977 Welche Datenpunkte wertest Du bei den von Dir rot eingekreisten Graphs aus?
Hast du es schon versucht Temperaturen aus dem Proxmox zu bekommen und auszuwerten?
Danke und Gruss
UrsHi Urs,
in den beiden Fällen sind es proxmox.0.node_homeserver.cpu und proxmox.0.qemu_iobroker.cpu bei mir.
Auch nach mehr als einem Tag ist die Last bedeutend besser geworden. Für meinen Teil hat sich das Update gelohnt
-
@AxelF1977 Danke
-
@Urs sagte in SQL-Adapter verursacht hohe CPU-Last:
@AxelF1977 Danke
Gerne, bin ja froh wenn ich auch mal helfen kann, und mir nicht nur geholfen wird
-
Moin, nach dem Update auf 3.1.5 ging es stetig aufwärts mit der Last. Heute Morgen
gegen 6 Uhr ging es radikal nach unten und im Log waren auch sehr viele Fehler kurz davor.
Mal sehen ob es wieder hoch geht oder sich beruhigt hat. Achja, die Extremspitzen waren
bei mir vom Adapter "DasWetter", warum auch immer.
-
@Nashra sagte in SQL-Adapter verursacht hohe CPU-Last:
Achja, die Extremspitzen warenbei mir vom Adapter "DasWetter", warum auch immer.
Kann ich bestättigen, Das Wetter und hue-extended verursachen bei mir auch eine höhere Last aktuell. Noch vor dem Javascript Adapter, die ansich gut zu tun hat.
MySQL bleibt bei ca. 3%
-
Nicht falsch verstehen, man sieht diese Spitzen hier sehr schlecht. Es war alles auf sehr hohem Niveau am laufen,
nur DasWetter haute noch mehr drauf. Die anderen Adapter waren auch für die hohe Last verantwortlich wie man
ja sieht. Komisch ist/war nur das es langsam angestiegen ist über ca. 24 Std. und heute Morgen dieser Einbruch
kam. Mal sehen was in den nächsten Stunden passiert. -
Einen kontinuierlichen Anstieg wie bei Dir konnte ich nicht beobachten. Aber trotzdem komisch, denn auch bei mir ist heute Nacht was los gewesen. Allerdings etwas früher und in die andere Richtung:
Einen eindeutigen Schuldigen konnte ich bisher nicht ausmachen. Bis auf den system.host.iobroker-Live der im Moment zwischen 5 und 10% CPU Last pendelt (vermutlich normal dass der erhöht ist?) scheinen alle anderen Adapter keine übermässigen CPU-Zeiten aufzuweisen. Aber da ich die Werte bisher nicht aufgezeichnet und auch nicht wirklich angeschaut habe ist es schwierig konkrete Aussagen dazu zu machen. Im Log hab ich auf die schnelle auch nichts wirklich auffälliges gefunden.Daswetter hat bei mir seit gestern gerade mal 0.35s cputime, ist aber auch alive = false. ist das bei euch auch so? Ist der nur alive wenn er Daten holt? Das wäre dann bei mir nur alle 30 Minuten.
-
@Urs sagte in SQL-Adapter verursacht hohe CPU-Last:
Daswetter hat bei mir seit gestern gerade mal 0.35s cputime, ist aber auch alive = false. ist das bei euch auch so? Ist der nur alive wenn er Daten holt? Das wäre dann bei mir nur alle 30 Minuten.
Jep, die extremen Spitzen waren bei mir auch alle 30 Minuten....DasWetter, nur alive wenn er Daten holt.
Aber bei mir steigt es wieder an, das ist doch nicht normal...
Was läuft:
admin 4.1.1
js-controller 3.1.5
Script-engine 4.6.17
Nodejs 12.18.0
NPM 6.14.4 -
Interessant ist, dass sich die ganze LAst der CPU auf nur 8 Adapter verteilt. Wobei 2 der Top 4 sogar deaktiviert sind...
Es gibt immer mal Spitzen, z.B. ca. 00:30 und ca. 12:30 Uhr ansonsten läuft ioBroker recht ruhig seit dem Update. Ich sehe bei mir keinen größeren Anstieg mehr.
-
Hmm...es gibt Sachen die muss ich nicht verstehen, bei mir ist inzwischen auch wieder alles im Lot:
Das einzige was ich um die Zeit als die Last wieder runter ging gemacht habe ist mich im Iobroker eingeloggt, ein paar cpu-Daten der Adapter und das Logbuch kurz angeschaut. Habe weder Iobroker noch irgend ein Adapter neu gestartet oder irgendwelche Änderungen daran ausgeführt. Komisch...
Aber egal, im Moment ist wieder alles im Lot, mal schauen wie lange.@AxelF1977 Noch was anderes: Womit hast Du Deine Visualisierung realisiert? Die steht nicht zufällig irgendwo online zur Verfügung? Ich sehe da nämlich immer wieder interessante Details...so jetzt wieder in der Übersicht der CPU-Auslastung...
Danke
Urs -
@Urs sagte in SQL-Adapter verursacht hohe CPU-Last:
@AxelF1977 Noch was anderes: Womit hast Du Deine Visualisierung realisiert? Die steht nicht zufällig irgendwo online zur Verfügung? Ich sehe da nämlich immer wieder interessante Details...so jetzt wieder in der Übersicht der CPU-Auslastung...
Danke
UrsHi Urs,
sobald das Projekt komplett fertig ist, stelle ich es in einem Thema vor. An sich gibt es da schon eins, aber ich habe das von Grund auf neu aufgebaut, bzw. bin noch an Details dran.
https://forum.iobroker.net/topic/27704/visualisierung-mit-material-design?page=1
Das ist alles sehr umfangreich, daher schaue ich dann mal, wie ich das dann exportiere.
Einige Widgets kann ich Dir aber schon mal liefern
Widgets kleine Diagramme CPU und RAM
Line-chart-cpuram.txtWidgets Kreisdiagramme, diese brauchen noch Datenpunkte
Kreisdiagramme.txt
Widget großes Diagramm CPU in eigene VIEW packen, _card_Diagramme_Proxmox_cpuram_ioBroker_cpu_popup
Line-chart-cpu.txtWidget großes Diagramm RAM in eigene VIEW packen, _card_Diagramme_Proxmox_cpuram_ioBroker_RAM_popup
Line-chart-ram.txtFunktioniert NUR mit dem Material Design Adapter und Uhulas Material Design CSS. Justgage muss auch vorhanden sein.
Bei Fragen gerne als private Nachricht
-
Nur zur Info, Übeltäter gefunden. Der Info-Adapter war durch ein Update wohl etwas
durcheinander bei den Einstellungen. Deaktiviert und schon ging die Last rapide runter.
-
admin 4.1.1
js-controller 3.1.5 - last auch mit 3.1.4 und auch mit 2.2.9
Script-engine 4.6.17
Nodejs 12.17.0
NPM 6.14.4bei mir ist die hohe last auch
habe viele einträge dieser art:
@apollon77 hast du vielleicht eine idee dazu ?
-
Moin, eigentlich wundert es mich das es so wenigen auffällt das die Last hochgeht.
Seit Tagen bin ich dies ja auch am beobachten und versuche den oder die Übeltäter
zu finden. Anbei ein Diagram wo man dies sieht und wo ich kurz vor 9 Uhr den
Javascript-Adapter neu gestartet habe.
admin 4.1.1
js-controller 3.1.5
Script-Engine 4.6.17
Nodejs 12.18.0
NPM 6.14.4Nachtrag:
Ich glaube nicht das es nur an der Script-Engine liegt da ich es auch mit älteren Versionen versucht habe.
Was mir aber dabei aufgefallen ist, das es mit diesen etwas länger dauert bis sich die CPU-Last wieder
langsam in Bereiche von über 50% bewegt.
