SQL-Adapter verursacht hohe CPU-Last
-
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. -
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
-
@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.
-
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.
-
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. -
@Nashra frage neuen unifi adapter auch jede minute ab- war bzw. macht bei mir kein problem
-
@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. -
- 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
-
@liv-in-sky sagte in SQL-Adapter verursacht hohe CPU-Last:
- 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.
-
@Nashra ist das auch, wenn du alle 3 minuten abfrägst?
-
@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
-
@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 installierenwürde das nicht fruchten, sollte der entwickler mal gefragt werden und "gebrainstormt" werden
-
@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 installierenwü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 -
@Nashra zu wenig ram ?- wird da evtl geswapt bei großen datenmengen
-
@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...
-
@Nashra
joi -sollte reichen - falls mir noch was einfällt , sage ich bescheid - im moment eher keine ideen mehr -
@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
-
@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.
-
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.5Docker 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
