93_DbLog - Umstellung Log-Funktion auf non-blocking

Begonnen von DS_Starter, 18 Dezember 2016, 20:03:56

Vorheriges Thema - Nächstes Thema

Tedious

Zitat von: DS_Starter am 23 Januar 2017, 18:21:42

Die Meldung liest sich für mich so als dass deine DB es nicht zulässt das Autocommit wieder einzuschalten. Läuft die DB evtl. nicht mit dem Default Autocommit on ? Nur eine Vermutung ...


Hallo Heiko,

Restart hat nix gebracht. Ich habe auf der Konsole explizit mit SET AUTOCOMMIT = 1; autcommit eingeschaltet. Fehler bleibt... scheinbar immer denn wenn ich auf DBLog-Plots zugreife...
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

DS_Starter

Hallo Tedious,

Synchron oder asynchmode ?
Bin noch unterwegs und schaue wenn ich wieder  Zeit habe.

Grüße
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Christian Uhlmann

Hallo zusammen,

Zitat von: Benni am 21 Januar 2017, 18:05:30
Ich hab' den Satz jetzt ungefähr 10 mal gelesen und werde einfach nicht schlau draus  :-\

ja, habe ich verstanden :)

Am Handy sowas zu schrieben ist nicht zielführend.

Ich wollt damit nur sagen, ich bin dafür, dass man die SQL Daten, welche DB, welcher Host und Port, welcher User, Pass und DB genutzt werden soll gerne in Attribute in das Modul verlagert werden können.
Alternativ würde ich die Datei basierte möglichkeit ebenso vorhanden lassen, vielleicht möchte das ja jemand so nutzen.
Ich denke das ganze aus einer Datei zu lesen, kommt aus dem Thema ConfigDB, da braucht es die Daten zwingend in einem File, da diese vor dem FHEM start gelesen werden müssen.

Generell würde ich trotzdem noch gerne meine Gedanken / wünsche anmerken, vielleicht hilft es ja, das Modul noch mehr zu nutzen.

  • Primär Schlüssel in die Vorlage für MySQL mit aufnehmen um pt-online-schema-change (https://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html) nutzen zu können
  • ausschließen von einzelnen Readings beim Loggen (ich Logge alles, würde aber gerne eine Hand voll Readings nicht loggen
  • Geräte bei denen ein reduceLog bzw. eine deleteOldDays nicht greift
  • readings bei denen ein reduceLog bzw. eine deleteOldDays nicht greift

Ansonsten habe ich das ganze hier auf einer dicken Maschine laufen mit einigen Geräten und vielen Werten die geloggt werden.
Maximum DB Size waren ~12 GB was ungefähr 50 Mio entsprach (ich weiß, ich bin faul und verrückt, aber die Hardware hat sonst nichts zu tun).
Alles in allem macht es viel Spaß, also noch mal danke für Eure Arbeit!

Wenn ich mal was testen soll, einfach anschreiben. Beim mitlesen, bin ich immer etwas hinterher, schaffe es nicht so viele Themen parallel zu verfolgen neben Arbeit, Kindern und den anderen Hobbys


Grüße

Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

JoeALLb

Hallo Christian,

Zitat von: Christian Uhlmann am 24 Januar 2017, 15:28:30
Ich wollt damit nur sagen, ich bin dafür, dass man die SQL Daten, welche DB, welcher Host und Port, welcher User, Pass und DB genutzt werden soll gerne in Attribute in das Modul verlagert werden können.
Und welches gewinnt dann? Ich würde das niemals doppelt haben wollen.

Zitat von: Christian Uhlmann am 24 Januar 2017, 15:28:30
Primär Schlüssel in die Vorlage für MySQL mit aufnehmen

Das wünsche ich mir auch, nutze ich auch schon! Jedoch sollten wir das in einem anderen Zusammenhang machen, nicht in dem dieses threads.

Zitat von: Christian Uhlmann am 24 Januar 2017, 15:28:30
ausschließen von einzelnen Readings beim Loggen (ich Logge alles, würde aber gerne eine Hand voll Readings nicht loggen
Geht doch schon, über DbLogExclude. Du kannst sogar entscheiden, ob generell alle geloggt werden sollen, und nur manche ausgenommen werden sollen, oder umgekehrt, ob generell keine readings geloggt und nur bestimmte geloggt werden sollen!

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

stromer-12

Datenbank ist nach reduceLog Arbeiten im Moment ca. 6GiB mit 26Millionen Datensätzen

Zitat von: JoeALLb am 24 Januar 2017, 11:21:14
Sammelt ein paar Messungen, die jetzt besonders lange dauern und deren Zeiten du kennst. (Count benötigt man ja selten ;-))
zB wäre dies eine Abfrage, die man benutzen kann um unnötig geloggte Devices zu erkennen!
select timestamp, device, reading, value, count(*) as Nr from history group by device, reading order by Nr DESC, device;
Bei Einschränkung auf 1/7 der Daten benötigt diese Abfrage auf meinem RPI3 21 Sekunden.
Hat bei mir auf die komplette Datenbank 1hour39min40sec gebraucht.

ZitatOder eine typische Abfrage aus den Plots:
SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1 AND DEVICE  = 'Heizung' AND READING = 'actuator' AND TIMESTAMP >= STR_TO_DATE('2017-01-23 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP < STR_TO_DATE('2017-01-24 00:00:01', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP limit 100;
Diese dauert bei mir bei kalter (frisch gestarteter) Datenbank 0,28s und eignet sich prinzipiell natürlich besonders gut für Tests, das Ergebnis ist aber fast schon zu schnell um genaue Aussagen machen zu können.
Hier brauchte mysql 0,1s.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

JoeALLb

Zitat von: stromer-12 am 24 Januar 2017, 18:47:54
Datenbank ist nach reduceLog Arbeiten im Moment ca. 6GiB mit 26Millionen Datensätzen
Hat bei mir auf die komplette Datenbank 1hour39min40sec gebraucht.
Das sind bei dir 4347,82 Datensätze pro Sekunde. Auf welchem System läuft dies? Habe gerade meinen RPI3 ergänzt, der 216560,50 Datensätze pro Sekunde bei einem Ergebnis von 4262 DS mit der genannt Konfiguration sortiert.(Habe meinen Beitrag um diese Info ergänzt) Wie viele Datensätze kamen bei Dir als Ergebnis?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

stromer-12

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

DS_Starter

Hallo zusammen,

anbei die V2.10.6 zum Test.

@friesenjung ... schau mal ob die Feldlängenerweiterung nun gleich nach dem Start zieht.

@Tedious ... konnte mit meiner MySQL/Mariadb deinen Sachverhalt nicht nachvollziehen. Habe aber noch mehr Funktionen innerhalb des Moduls voneinander entkoppelt (eigenes DB-Handle). Schau mal ob eine Verbesserung eingetreten ist.

Ich hoffe nichts vergessen zu haben. War schon spät heute, bei mir klappt aber alles mit dieser Version und MySQL/SQLite.

viele Grüße
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Tedious

Hi,

danke fürs Feedback. Schaue ich mir heute Abend mal an, besten Dank!

Grüße Sascha
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Christian Uhlmann

Hallo Joe,

Zitat von: JoeALLb am 24 Januar 2017, 17:51:34
Geht doch schon, über DbLogExclude. Du kannst sogar entscheiden, ob generell alle geloggt werden sollen, und nur manche ausgenommen werden sollen, oder umgekehrt, ob generell keine readings geloggt und nur bestimmte geloggt werden sollen!
Ich dachte da eher an eine zentrale Stelle und nicht in jedem Device. So wie es mit excludeDevs für Devices ja schon geregelt ist.


Grüße
Christian
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

Benni

Zitat von: Christian Uhlmann am 25 Januar 2017, 09:32:33
Ich dachte da eher an eine zentrale Stelle und nicht in jedem Device.

Die Readings am Device einzuschränken ist m.E. schon die richtige stelle, schließlich gehören die Readings ja zum Device. Und nur weil Readings an unterschiedlichen Devices gleich heißen, bedeutet das noch lange nicht, dass sie auch das gleiche beinhalten.

Ich kann die entsprechende RegEx für die Einschränkung an den jeweiligen Devices ja, bei Bedarf über devspec quasi global setzen.

JoeALLb

Zitat von: Benni am 25 Januar 2017, 11:23:05
Ich kann die entsprechende RegEx für die Einschränkung an den jeweiligen Devices ja, bei Bedarf über devspec quasi global setzen.
Oder über die Nutzung von archetype verteilen.
Eine zusätzliche Einschränkunf über DbLogExclude hinaus würde ich für extrem verwirrend halten!

Das zentrale excludeDevs hat Performancevorteile und hat dadurch seine Berechtigung.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Tedious

#462
Zitat von: DS_Starter am 25 Januar 2017, 01:11:41


@Tedious ... konnte mit meiner MySQL/Mariadb deinen Sachverhalt nicht nachvollziehen. Habe aber noch mehr Funktionen innerhalb des Moduls voneinander entkoppelt (eigenes DB-Handle). Schau mal ob eine Verbesserung eingetreten ist.

Schaut besser aus! Fehlermeldungen sind weg, auch die damit verbundenen Abstürze von FHEM scheinen Vergangenheit zu sein. Danke.

EDIT: zu früh gefreut.

DBD::mysql::db rollback failed: Turning on AutoCommit failed at ./FHEM/93_DbLog.pm line 1107.

Mit der Meldung stürzt FHEM stumpf ab. Schade, seit den Änderungen im Modul läuft das echt grottig bei mir  :(
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

DS_Starter

Hallo Sascha,

ZitatMit der Meldung stürzt FHEM stumpf ab. Schade, seit den Änderungen im Modul läuft das echt grottig bei mir

Echt eigenartig dass du diese Autocommit-Meldung jetzt auch noch bekommst. Mit meiner MySQL/MariaDB habe ich keinerlei Sorgen damit.
Ich bekomme es sicher noch so abgefangen dass FHEM deswegen nicht abstürzt. Aber der eigentlich Grund dafür ist mir nicht einleuchtend.

Versuche doch mal in den asynchronen Modus zu wechseln ob dies Problem dann immer noch besteht.

Ich schaue heute Abend /morgen wie ich zumindest die negative Auswirkung dieser Meldung für dich beseitigen kann.

Grüße
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Tedious

Zitat von: DS_Starter am 26 Januar 2017, 12:43:18
Versuche doch mal in den asynchronen Modus zu wechseln ob dies Problem dann immer noch besteht.

Hi, danke für den input.

.done

Mal schauen was passiert, danke :)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...