SQL-Adapter verursacht hohe CPU-Last

[liv-in-sky]

konnte meine last erstmal wieder runter bekommen

habe gestern objekte importiert zum teten eines scriptes - darin waren viele dtenpunkte für einen eintrag in die history angeklickt - habe alle diese einträge gelöscht

scheint im moment wieder zu funktionieren - last ist wieder wie üblich - ca. 10% - außer bei speedtest, da wird es wieder höher

werde mal weiter beobachten, was passiert, wenn länger läuft

[Dr. Bakterius]

@Nashra sagte in SQL-Adapter verursacht hohe CPU-Last:

eigentlich wundert es mich das es so wenigen auffällt das die Last hochgeht.

Vielleicht weil das nicht bei jedem so ist? So sieht die CPU-Last meines Proxmox-LCX über die vergangenen 7 Tage aus:

Da steigt nichts an.

[Nashra]

Ich verstehe es ja auch nicht @Dr-Bakterius da es monatelang ohne Probleme lief. Nach der Restart
der Script-Engine heute morgen fängt es jetzt langsam wieder an zu steigen.

[Nashra]

Tach auch, Problem der hohen CPU-Last lokalisiert
Zuerst, in Common und Global waren noch zwei alte Scripte (Eventlist) aktiviert und
dann noch der DasWetter-Adapter und der Unifi-Adapter deaktiviert.
Danach war Ruhe d.h. die Scripte sind egal aber das die zwei Adapter beim Daten laden
bis zu 70% Cpu-Last haben das geht mal gar nicht. Der schlimmste hierbei ist der
Unifi da dieser im Minutentakt abfragt. DasWetter holt nur alle 2 Stunden jetzt aber der Unif
muß dran glauben obwohl ich das Teil bräuchte.

[liv-in-sky]

@Nashra frage neuen unifi adapter auch jede minute ab- war bzw. macht bei mir kein problem

[Nashra]

@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:

@Nashra frage neuen unifi adapter auch jede minute ab- war bzw. macht bei mir kein problem

Hm, bei mir läuft IO im LXC Container und ob es daran liegt bezweifle ich.
Habe Unifi vorhin um 17:20 aktiviert, schau dir mal die Grafik an, nicht normal

und um ca 17:30 wieder deaktiviert weil mir das zu doll wird.

[liv-in-sky]

@Nashra

• hast du ein script, das darauf (adapter datenpunkte) reagiert und einen fehler hat
• hast du das unifi script deaktiviert
• ist das auch, wenn du alle 3 minuten abfrägst?

mehr fällt mir im moment nicht ein

[Nashra]

@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:

@Nashra

• hast du ein script, das darauf (adapter datenpunkte) reagiert und einen fehler hat
• hast du das unifi script deaktiviert

mehr fällt mir im moment nicht ein

Nö alles deaktiviert. Ich hole auch nur die Daten für die Anwesenheit der Handy's, sonst nichts.

[liv-in-sky]

@Nashra ist das auch, wenn du alle 3 minuten abfrägst?

[Nashra]

@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:

@Nashra ist das auch, wenn du alle 3 minuten abfrägst?

Ja, steht schon auf 3. Mit deinem Script hatte ich nie so einen Ärger

[liv-in-sky]

@Nashra zur not würde ich den adapter stoppen - die settting kopieren und alle datenpunkte des adaptes löschen
dann adapter löschen - evtl sogar iobroker restart und adapter nochmal neu installieren

würde das nicht fruchten, sollte der entwickler mal gefragt werden und "gebrainstormt" werden

[Nashra]

@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:

@Nashra zur not würde ich den adapter stoppen - die settting kopieren und alle datenpunkte des adaptes löschen
dann adapter löschen - evtl sogar iobroker restart und adapter nochmal neu installieren

würde das nicht fruchten, sollte der entwickler mal gefragt werden und "gebrainstormt" werden

Leider genau dies schon am Wochenende probiert.
Die ganz alte Version des Adapters hatte ja auch schon das Problem mit der Last

[liv-in-sky]

@Nashra zu wenig ram ?- wird da evtl geswapt bei großen datenmengen

[Nashra]

@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:

@Nashra zu wenig ram ?- wird da evtl geswapt bei großen datenmengen

Dies dürfte reichen...

[liv-in-sky]

@Nashra
joi -sollte reichen - falls mir noch was einfällt , sage ich bescheid - im moment eher keine ideen mehr

[Nashra]

@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:

@Nashra
joi -sollte reichen - falls mir noch was einfällt , sage ich bescheid - im moment eher keine ideen mehr

@liv-in-sky Trotzdem Danke

[s.bormann]

@Bluefox @apollon77 Hi, bei mir macht der SQL-Adapter auch Probleme. Hohe Prozessorlast. Nach deaktivieren von SQL alles gut. Nach neuem aktivieren langsamer Anstieg über mehrere Stunden, bis fast nix mehr ging... Das lief vorher ewig ohne Probleme. SQL und js-controller sind aus dem latest.

[bvol]

ich bin bei Euch, bei mir sieht es genauso aus....

Vermutlich konnte ich das nun lösen und erfolgreich wieder auf stabile wechseln. Aus meiner Sicht ist der ursprüngliche Auslöser Adapter "sql": 1.13.1

Warum auch immer bin ich in den latest abgerutscht und hatte plötzlich massive Probleme mit der CPU Last im Docker auf meiner DS.

Ich habe ein Downgrade aus dem Latest hin zum. Stable gemacht.

pkill io
npm install iobroker.admin@4.0.10
npm install iobroker.flot@1.9.2
npm install iobroker.hm-rega@2.5.5
npm install iobroker.hm-rpc@1.14.2
npm install iobroker.hue@3.3.2
npm install iobroker.info@1.7.2
npm install iobroker.simple-api@2.4.5
npm install iobroker.socketio@3.0.7
npm install iobroker.vis@1.2.4
npm install iobroker.weatherunderground@3.1.6
npm install iobroker.web@3.0.8
npm install iobroker.js-controller@3.1.4
npm install iobroker.sql@1.12.5

Docker Container neu gestartet und erstmal Freude gehabt. Plötzlich ging aber die CPU wieder durch die Decke....

Da ich eine zweite nahezu identische Installation habe, mit genau den gleichen Paketversionen und aktiven Instanzen, konnte nur noch die DB einen Einfluss haben. Diese habe ich dann via phpMyadmin kopiert und siehe da, in der ts_number Tabelle war ein haufen Schrott drin, den phpMyadmin nicht kopieren wollte. Somit habe ich dann den entschrotteten Inhalt auf der neuen DB und siehe da, bisher ist die sql.0 Instanz wieder bei 0.3% - da wo sie auch hingehört.

Meine Vermutung ist nun, dass sql 1.13.1 irgendein Quatsch mit der DB anstellt

[Urs]

@AxelF1977 Danke für die Widgets. Sorry, hat etwas gedauert, hatte ein Problem mit dem Proxmox und etliche Fehlermeldungen im Iobroker und musste das zuerst noch hinbiegen. Daher hab ich deine Widgets auch noch nicht näher angeschaut...
Muss auch überlegen ob ich im VIS noch weitermache, denn bei der Suche nach Lösungen zu meinen anderen Fehlern bin ich über lovelace gestolpert. Nach 4 Tagen bin ich da wesentlich näher an eine brauchbare Visualisierung als im VIS nach 3 Monaten...natürlich hat sowohl VIS wie auch lovelace Vor- und Nachteile...mal schauen was daraus wird, ich freu mich auf jeden Fall wenn Du Dein Projekt mal vorstellst.

@bvol Wie sah der Datenmüll konkret aus? Auf den ersten Blick erkennbar oder auf den ersten Blick plausible Daten? Hab meine Daten mal überflogen und ein paar Stichproben bezüglich Plausibilität gemacht und die sehen unauffällig aus.

@all Bin nicht sicher ob das Problem beim SQL-Adapter oder bei anderen Adaptern oder in deren Kombination zu suchen ist.
Bei mir dümpelt das Teil seit ein paar Tagen so unauffällig wie es sein sollte vor sich hin. Bei mir lag es, wie weiter oben schon geschrieben, an den beiden internet-speed-Adapter (Vodafone und Speedy) in Kombination mit SQL. Auch hatte ich immer wieder Fehler wie die folgenden:

gree_aircon.0	2020-06-07 00:53:52.613	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.612	warn	(1358) Object gree_aircon.0.quiet is invalid: obj.common.type has an invalid value (text) but has to be one of number, string, boolean, array, object, mixed, file, json
gree_aircon.0	2020-06-07 00:53:52.607	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.607	warn	(1358) Object gree_aircon.0.air is invalid: obj.common.type has an invalid value (text) but has to be one of number, string, boolean, array, object, mixed, file, json
gree_aircon.0	2020-06-07 00:53:52.606	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.605	warn	(1358) Object gree_aircon.0.fanSpeed is invalid: obj.common.type has an invalid value (text) but has to be one of number, string, boolean, array, object, mixed, file, json
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, json

yamaha.0	2020-06-07 01:39:44.586	warn	(1028) This object will not be created in future versions. Please report this to the developer.
yamaha.0	2020-06-07 01:39:44.585	warn	(1028) Object yamaha.0.volume is invalid: obj.common.type has an invalid value (integer) but has to be one of number, string, boolean, array, object, mixed, file, json
yamaha.0	2020-06-07 01:39:44.583	warn	(1028) This object will not be created in future versions. Please report this to the developer.
yamaha.0	2020-06-07 01:39:44.583	warn	(1028) Object yamaha.0.Commands.adjustVolume is invalid: obj.common.type has an invalid value (integer) but has to be one of number, string, boolean, array, object, mixed, file, json
yamaha.0	2020-06-07 01:39:44.582	warn	(1028) This object will not be created in future versions. Please report this to the developer.
yamaha.0	2020-06-07 01:39:44.581	warn	(1028) Object yamaha.0.Commands.volumeDown is invalid: obj.common.type has an invalid value (integer) but has to be one of number, string, boolean, array, object, mixed, file, json
yamaha.0	2020-06-07 01:39:44.580	warn	(1028) This object will not be created in future versions. Please report this to the developer.
yamaha.0	2020-06-07 01:39:44.579	warn	(1028) Object yamaha.0.Commands.volumeUp is invalid: obj.common.type has an invalid value (integer) but has to be one of number, string, boolean, array, object, mixed, file, json

Insgesamt gab es die Fehler bei 10-15 Adapter von ungefähr 30. Lösung war de- und wieder installieren der entsprechenden Adapter. Bis auf den Mihome-Vacuum sind alle seitdem Ruhig. Einzig der Mihome war gestern auf gelb (seit wann weiss ich nicht) und brachte beim Neustart wieder folgendes:

mihome-vacuum.0	2020-06-17 18:05:05.413	warn	(607877) This object will not be created in future versions. Please report this to the developer.
mihome-vacuum.0	2020-06-17 18:05:05.412	warn	(607877) Object mihome-vacuum.0.info.dnd is invalid: obj.common.type has an invalid value (switch) but has to be one of number, string, boolean, array, object, mixed, file, json

Seit dem Neustart gestern keine Probleme mehr. Keine Ahnung ob zwischen den Fehlern und der Auslastung ein Zusammenhang besteht, denn wie geschrieben ist die bei mir im Moment ok. Vielleicht sind das auch Folgefehler vom Upgrade vom js-controller oder anderer Adapter...

Gruss
Urs

[bvol]

@Urs Bei mir waren string datensätze in der ts_number tabelle. Betroffene Adapter: weatherunderground, coronavirus-statistics, netatmo usw., also eigentlich alle adapter, die strings liefern. Die hm-* adapter waren nicht betroffen, da die keine strings liefern.
Wirklich Ruhe ist bei mir erst eingekehrt, nachdem ich konsequent alle string Lieferanten vom logging excluded habe. Zudem waren haufenweise Dubletten in der DB, was man recht schnell mit einer Kopie der Tabellen via sql sehen kann. So hatte die ts_number Tabelle, die zuvor 12Mio Datensätze hatte, nach der Kopie nur noch 8 Mio Datensätze...

Ich habe den Ärger nun auch genutzt und die Tabellen via php Script entrümpelt und alle Datensätze mit sort by id asc, ts asc eingelesen und dann, wenn val und id gleich waren, Zeile für Zeile geprüft und nur die nicht gleichen Datensätze in eine neue Tabelle geschrieben. Jetzt hat z.B. die ts_number nur noch 1.2 Mio Datensätze. Man sollte auf dem SQL Adapter einfach nie „trotzdem gleiche Werte aufzeichnen (Sekunden)“ aktivieren....

Die String Werte (weatherunderground) lese ich jetzt via simple-api aus und schreibe sie dann auch via simple-api in die richtige Tabelle. Das Ganze via php und halt nur für die Werte, die ich sowieso nur von Zeit zu Zeit pullen will.

Meine sql.0 Instanz konsumiert nun nur noch 0.3% mit Peaks bis 1% CPU im Docker Container, zuvor waren es dauerhaft 90-100%!

Gleiches habe ich auch auf einer zweiten, durch mich betreuten Installation durchgeführt, mit gleichem Ergebnis. Hierbei bin ich aber über ein MySQL Performance Thema gestolpert: Ich nutze ein Synology DS 918+ mit NVME cache, dort schluckte die MariaDB die sql inserts fast in Echtzeit (ca. 1Mio records pro Minute), auf der zweiten Installation auf einer DS 216+II war das Disksystem sofort am Anschlag und ich konnte nur knapp 10'000 records pro Minute schreiben.