SQL-Adapter verursacht hohe CPU-Last

[liv-in-sky]

@apollon77

der wird doch mitgelöscht, wenn man die datenpunkte löscht ? oder

habe mal abgefragt:

log(getState('maxcube.0.devices.thermostat_101881.setpoint').val)

[apollon77]

@liv-in-sky Ja sollte er ... ich versuche es zu verstehen ... Also alles ausschliessen

An sich liesst der sql Adapter zu Beginn die Objekte die ein custom haben ... also wenn Objekte gelöscht sind sollte er die nie bekommen

[liv-in-sky]

@apollon77

genau so hätte ich mir das auch vorgestellt

wenn ich mit dem tool in der datenbank suche nach max kommt auch nix

[liv-in-sky]

@apollon77

in der sql datenbank ist noch was - aber das ist wohl das problem

[apollon77]

@liv-in-sky Nein ist es nicht. Dem Adapter ist egal was in der DB steht. Er nimmt die Objekte die sql aktiviert haben und arbeitet damit. Er schaut nur dann in der DB nach ob ein Objekt schon bekannt ist oder nicht.

[liv-in-sky]

@apollon77 aber wo kann den noch was in redis oder in den objekten (text) sein - beides des dp's ist weg

gib bitte bescheid, wenn ich noch was nachschauen soll

[apollon77]

@liv-in-sky Genau DAS verstehe ich noch nicht

[Dr. Bakterius]

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

Dem Adapter ist egal was in der DB steht ... kann es sein das aus irgend einem Grund nur der STate gelköscht ist aber das Objekt noch da ist ... ja das Thema steht noch auf der Liste ...

Verstehe jetzt nicht wirklich was du meinst. Ich habe die Aufzeichnung eines Datenpunktes gestoppt. Bei nächsten Start des SQL-Adapters kamen genau diese Meldungen der Objekte die nicht mehr geloggt wurden (die es aber noch gibt). In der DB waren die datapoints-Einträge und die Werte (ts_number) noch vorhanden. Nachdem ich diese gelöscht hatte, waren auch die Meldungen vom Adapter weg.

[Urs]

Das Verhalten kann ich in einer etwas geänderten Form bestätigen. Ich hatte mehrere Adapter welche Daten in die DB geschrieben haben komplett deinstalliert. Es waren somit auch keine Datenpunkte mehr vorhanden. Seut da bekam ich die Fehler.
Ich hab es damals darauf geschoben dass ich die DP nicht deaktiviert habe bevor ich die entsprechenden Adapter deinstalliert habe, ob das wirklich so ist hab ich nicht weiter recherchiert.

Auch bei mir waren die Fehler erst weg als ich die entsprechenden Einträge in der Datenbank von Hand gelöscht habe.

Gruss
Urs

[apollon77]

Ok, das waren die ausschlagebenden Hinweise ... ich glaub ich habs. Bitte 1.15.2 testen

[liv-in-sky]

@apollon77
bekomme nun keine warnungen mehr beim start der instanz - danke

werden die werte in der datenbank nun auch gelöscht oder ist das unwichtig?

[apollon77]

@liv-in-sky Der Adapter aktuell macht kein Löschen. Admin 5 wird das Dinge mitbringen um das per Admin zu tun

[etv]

@apollon77 said in SQL-Adapter verursacht hohe CPU-Last:

@Dr-Bakterius Dem Adapter ist egal was in der DB steht ... kann es sein das aus irgend einem Grund nur der STate gelköscht ist aber das Objekt noch da ist ... ja das Thema steht noch auf der Liste ...

@etv
mach bitte mal an der Kommandozeile

iobroker object get vodafone-speedtest.0.Results.ping.packetLoss

und

iobroker state get vodafone-speedtest.0.Results.ping.packetLoss

Und sag mal was das gibt

...da ist @Urs gemeint.....

[Urs]

Kann ich gerne machen, aber im Moment bringt es grad nichts da ich den Adapter, als sich die Probleme im Zusammenhang damit zeigten, runter geworfen habe. Daher geben die Befehle im Moment (wie zu erwarten war) nur ein object Voodafone...not found zurück.

Kann den gerne nochmal installieren, aber das muss etwas warten, denn morgen muss ich beizeiten weg also fällt eine Nachtschicht wenn was schief läuft flach. Danach bin ich einige Zeit nicht daheim und die (leidvollen) Erfahrungen haben gezeigt dass "never change a running system" gerade über VPN ohne physischem Zugriff auf die Komponenten noch wahrer ist als sonst

In 2-3 Wochen gerne wieder, falls dann noch aktuell...

Danke auf jeden Fall für die Arbeit am Adapter.

Gruss
Urs

[apollon77]

Ist alles schon überholt. SOllte in neuester Latest Version gefixt sein