93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

Kaufe · 16 Februar 2017, 07:31:09

Hallo zusammen,

habe die letzten Tage auch von FileLog auf DBLog migriert und musste leider feststellen das die MariaDB auf dem Raspberry vielleicht in meinem Falle nicht so eine gute Idee ist, die Plots dauern ca 10-20 Sekunden und der arme Raspberry läuft auf 100% CPU (MySQL Process 1-2 Cores).

In der Datenbank sind ca 13 Mio Datensätze, der letzten 6 Monate, bei ca 30 Devices. Im Monat kommen im Schnitt 1-2 MIO Datensätze hinzu. Die Datenbank habe ich schon mal auf eine SSD Platte (die aber leider über USB angeschlossen ist) geschoben.

In einer alten Firma hatten wir ein ähnliches Problem (wenn ungleich die Hardware viel größer war, doch 2 TB im Monat Daten war auch da eine Hausnummer). Dort hatten wir es dann so gelöst das wir einen insert und select trigger in der Postgres gebaut haben. Diese hatte die Daten in die unterschiedlichen Tabellen geschrieben.
Der insert ging z.B auf history, der trigger hatte dieses dann aber in die Tabelle history_201702 geschrieben. Somit hatten wir "schlankere Tabellen" und auch kleinere Indexe. But not Least war das Löschen der alten Daten einfach ein "drop table_201610". Der Select konnte normal auf "history" gehen und der trigger wusste ja wo der Timestamp zu finden ist.

Beispiel:
Datum 12.12.2016
-> history = Trigger auf history_201612

Datum 01.01.2017
-> history = Trigger auf history_201701

Es gibt natürlich auch einen Nachteil, zwar müssen die Tabellen davor natürlich existieren. Dafür hatten wir einen Cronjob gebaut der einmal im Monat gelaufen ist, der hatte überprüft ob die nächsten 3 Monate schon Tabellen existieren und wenn nicht existierten dann gleich die nächsten 3 Monate angelegt hat.

Was haltet ihr von dem Gedanken?

JoeALLb · 16 Februar 2017, 08:25:12

Ich denke nicht, dass Du zwei Tabellen benötigst.
Trigger brauchen auch CPU-Zeit und eigentlich gibt es (zumindes auf meinen RPIs) keinen Engpass.

Aber das ist genau der Grund, warum es diesen Thread hier gibt.

1. Frage: Verwendest Du current/history? Wenn ja, stell doch mal auf nur "history" um. Die Persormance sollte gleich spürbar besser werden.
2. Dann würde ich das Tabellenformat und die Indexe umstellen, und auf die neue Testversion von DbLog umstellen,
die in diesem Thread anhegängt wurde und bereits die PK-Indexe unterstützt. Wenn Du dann noch auf async=1 umstellst, sollte
deine Plots besser funktionieren als zuvor mit Filelog.

Kaufe · 16 Februar 2017, 11:06:00

Hi @JoeALLb,

danke für deine Tips, habe schon mal folgendes gesetzt:

Code Auswählen

attr DbLog_FHEM DbLogType History
attr DbLog_FHEM asyncMode 1

Zeiten haben sich aber beim GPLOT nicht geändert, dauerte davor ca 11 Sekunden und dauert auch jetzt noch 11 Sekunden.
Ein Fulltablescan (Select coun(*) from historys) dauert allerdings 1 Minute 20 Sekunden. Dabei liefert die Platte 10 MB/s und 1500 IOs

Wo finde ich denn das neue Tabellenformat? Dann würde ich das heute abend gerne mal testen. Werde die Datenbank noch neu importieren, denn die innodb ist schon bei 6.5 GB, Datenbank selber hat aber "nur" 1.2 GB.

Danke schon mal für die unterstützung.

JoeALLb · 16 Februar 2017, 11:22:55

Hier in diesem Thread
https://forum.fhem.de/index.php/topic,62998.msg568302.html#msg568302

Folgende Anmerkung:
#1 Mach Index 1 als Primary Key, da DbLog aus diesem Thread mittlerweile einen PK-Support hat!
#2 verwende das Modul DbLog aus diesem Thread (Kommentar #119 denk ich)
#3 Du kannst die Partitionen weglassen, die sind hauptsächlich für RPIS gedacht, die die DB auf einer SD-Karte gespeichert haben (so wie ich auf einem RPI)
#3: Die Datenbankgröße wird immer größer sein wie die Filelog-Größe.

Neuimport sollte nicht nötig sein, mit dem insert into select from kopierst du die Daten relativ schnell innerhalb von MySQL.
Achtung: InnoDB gibt manchmal einen Fehler beim lesen von mehr als 1Mio Datensätzen aus, wenn dem so ist, meld dich nochmal.

Edit: Ergänzt

JoeALLb · 16 Februar 2017, 14:17:27

Zitat von: Kaufe am 16 Februar 2017, 07:31:09
Was haltet ihr von dem Gedanken?

Nachtrag:
Hier in meinem Benchmark(https://forum.fhem.de/index.php/topic,65860.msg585475.html#msg585475) sieht man aber, dass jede Client/Server Datenbank längsamer ist als SqLite (19s vs. 30s),
jedoch für 150 Devices für eine ganze Woche. Ich denke also dass es auch mit MySQL/MariaDB schnell genug sein sollte
bei jedem Plot. Die Vorteile dieser DBs halte ich jedoch für größer wie diesen Nachteil!

Kaufe · 16 Februar 2017, 21:20:58

Hi JoeALLb,

super, ich danke dir vielmals.

Testergebniss davor:
#################
-> ein spezieller PLOT(mit 4 verschiedenen Devices) dauerte ca 11 Sekunden
-> 173 rows in set (4 min 7.63 sec) von dem SQL"select timestamp, device, reading, value, count(*) as Nr from history group by device, reading order by Nr DESC, device; "

* Habe mal das neue V2.13 vom 93_DbLog installiert.
* die Datenbanken neu aufgebaut wie du beschrieben hast
* Die Datenbank importiert

Code Auswählen

Query OK, 12995574 rows affected (41 min 12.63 sec)
Records: 13135326  Duplicates: 139752  Warnings: 0

* Datenbank wieder umbenannt

Wieder Tests gemacht:
##################
-> ein spezieller PLOT(mit 4 verschiedenen Devices) dauerte nun zwischen 5 und 7 Sekunden
-> 173 rows in set (1 min 38.98 sec) von dem SQL"select timestamp, device, reading, value, count(*) as Nr from history group by device, reading order by Nr DESC, device; "

Abschließend habe ich mein GPLOT noch überprüft und auch hier die Übeltäter gefunden:

Zitat#DbLog_FHEM GA_Garage1
#DbLog_FHEM AU_Garage1
#DbLog_FHEM AU_Garage2
#DbLog_FHEM AU_Haustuere

ist natürlich falsch, habe das nun abgeändert, das auch dei Readings ins SQL bzw in den Index fallen.

Zitat#DbLog_FHEM GA_Garage1:temperature
#DbLog_FHEM AU_Garage1:temperature
#DbLog_FHEM AU_Garage2:temperature
#DbLog_FHEM AU_Haustuere:temperature

Nun braucht auch das 6 Sekunden Plot, nur noch ein gefühltes Augenzwinkern.

Geniale Arbeit. DANKE schon mal vielmals

DS_Starter · 17 Februar 2017, 17:17:58

Hallo miteinander,

ich habe die Hinweise von Dan aufgegriffen und "clearReadings" dahingehend geändert dass die Readings nur noch geleert werden (außer
state und periodisch wiederkehrende Readings mit asynch=1).
Um alle Readings (außer "state") zu löschen, gibt es jetzt den Befehl "eraseReadings". Somit hat sicherlich jeder zur Verfügung was er an dieser Stelle wünscht.

Desweiteren habe ich eine non-blocking Variante von deleteOldDays eingebaut. Sie heißt deleteOldDaysNbl.
Insgesamt habe ich, dem Wunsch von betateilchen folgend, die bisherigen Funktionen von count, aber auch von deleteOldDays, reduceLog im Modul gelassen und
die nicht-blockierenden Varianten mit dem Zusatz "Nbl" versehen hinzugefügt.

Es gibt also nun "set <name> ... ":

* count (alt) bzw. countNbl (non-blocking)
* reduceLog (alt) bzw. reduceLogNbl (non-blocking)
* deleteOldDays (alt) bzw. deleteOldDaysNbl (non-blocking)

Ich denke damit gibt es für jeden Geschmack bzw. Bedarf eine entsprechende Funktion.
Die Commandref ist ebenfalls angepasst.

Bitte testet diese neue Version 2.13.2 wieder auf euren Systemen und gebt bitte Rückmeldung ob alles soweit ok ist.

viele Grüße
Heiko

DeeSPe · 17 Februar 2017, 18:51:57

Zitat von: DS_Starter am 17 Februar 2017, 17:17:58
Hallo miteinander,

ich habe die Hinweise von Dan aufgegriffen und "clearReadings" dahingehend geändert dass die Readings nur noch geleert werden (außer
state und periodisch wiederkehrende Readings mit asynch=1).
Um alle Readings (außer "state") zu löschen, gibt es jetzt den Befehl "eraseReadings". Somit hat sicherlich jeder zur Verfügung was er an dieser Stelle wünscht.

Desweiteren habe ich eine non-blocking Variante von deleteOldDays eingebaut. Sie heißt deleteOldDaysNbl.
Insgesamt habe ich, dem Wunsch von betateilchen folgend, die bisherigen Funktionen von count, aber auch von deleteOldDays, reduceLog im Modul gelassen und
die nicht-blockierenden Varianten mit dem Zusatz "Nbl" versehen hinzugefügt.

Es gibt also nun "set <name> ... ":

* count (alt) bzw. countNbl (non-blocking)
* reduceLog (alt) bzw. reduceLogNbl (non-blocking)
* deleteOldDays (alt) bzw. deleteOldDaysNbl (non-blocking)

Ich denke damit gibt es für jeden Geschmack bzw. Bedarf eine entsprechende Funktion.
Die Commandref ist ebenfalls angepasst.

Bitte testet diese neue Version 2.13.2 wieder auf euren Systemen und gebt bitte Rückmeldung ob alles soweit ok ist.

viele Grüße
Heiko

Ui ui ui, da hast Du Dir aber wieder viel Arbeit gemacht Heiko!
Bisher sieht es bei mir auf MySQL gut aus.

Gruß
Dan

est · 18 Februar 2017, 09:39:13

Hallo,

als erstes mal vielen Dank für die viele Arbeit die ihr hier reinsteckt.

Ich bräuchte bitte mal etwas Hilfe. Seit gestern abend erhalte ich den Fehler: Commit already running - resync at NextSync
Ich nutze fhem auf einem Ubuntu Server (mit ESX virtualisiert). MySQL läuft auf dem gleichen Server. list myDbLog liefert:

Code Auswählen

Internals: 
   CFGFN 
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32 
   CONFIGURATION ./FHEM/FhemUtils/db.conf 
   DBMODEL    MYSQL 
   DEF        ./FHEM/FhemUtils/db.conf ^HK.*|^Kollektor.*|^Solar.*|^Speicher.*|^Steuerung.*|^Therme.*|^WW.*|.*:.* 
   MODE       asynchronous 
   NAME       myDbLog 
   NR         6 
   NTFY_ORDER 50-myDbLog 
   PID        28818 
   REGEXP     ^HK.*|^Kollektor.*|^Solar.*|^Speicher.*|^Steuerung.*|^Therme.*|^WW.*|.*:.* 
   STATE      Commit already running - resync at NextSync 
   TYPE       DbLog 
   VERSION    2.11.1 
   dbconn     mysql:database=fhem;host=localhost;port=3306 
   dbuser     fhem 
   Helper: 
     COLSET     1 
     DEVICECOL  64 
     EVENTCOL   512 
     READINGCOL 64 
     TYPECOL    64 
     UNITCOL    32 
     VALUECOL   128 
     Running_pid: 
       abortFn    DbLog_PushAsyncAborted 
       arg        myDbLog|MjAxNy0wMi0xNyAyMjoxMTozNXxIS1ZvcmxhdWZWYWx1ZXxEVU1NWXwzNC45fHN0YXRlfDM0Ljl8wqcyMDE3LTAyLTE3IDIyOjExOjM1fFNvbGFyV1RWb3JsYXVmfERVTU1ZfDIxLjZ8c3RhdGV8MjEuNnzCpzIwMTctMDItMTcgMjI6MTE6MzZ8T0dfRVpfVGhlcm1vc3RhdHxDVUxfSE18aHVtaWRpdHk6IDY2fGh1bWlkaXR5fDY2fCXCpzIwMTctMDItMTcgMjI6MTE6MzZ8T0dfRVpfVGhlcm1vc3RhdHxDVUxfSE18bWVhc3VyZWQtdGVtcDogMTMuMnxtZWFzdXJlZC10ZW1wfDEzLjJ8wqcyMDE3LTAyLTE3IDIyOjExOjM2fE9HX0VaX1RoZXJtb3N0YXR8Q1VMX0hNfFQ6IDEzLjIgSDogNjZ8VHwxMy4yIEh8NjbCpzIwMTctMDItMTcgMjI6MTE6MzZ8T0dfRVpfVGhlcm1vc3RhdF9XZWF0aGVyfENVTF9ITXxodW1pZGl0eTogNjZ8aHVtaWRpdHl8NjZ8JcKnMjAxNy0wMi0xNyAyMjoxMTozNnxPR19FWl9UaGVybW9zdGF0X1dlYXRoZXJ8Q1VMX0hNfG1lYXN1cmVkLXRlbXA6IDEzLjJ8bWVhc3VyZWQtdGVtcHwxMy4yfMKnMjAxNy0wMi0xNyAyMjoxMTozNnxPR19FWl9UaGVybW9zdGF0X1dlYXRoZXJ8Q1VMX0hNfFQ6IDEzLjIgSDogNjZ8VHwxMy4yIEh8NjbCpzIwMTctMDItMTcgMjI6MTE6MzZ8SEtSdWVja2xhdWZUZW1wMnxEVU1NWXwzOC4yfHN0YXRlfDM4LjJ8wqcyMDE3LTAyLTE3IDIyOjExOjM2fFNvbGFyTGVpc3R1bmd8RFVNTVl8MHxzdGF0ZXwwfMKnMjAxNy0wMi0xNyAyMjoxMTozNnxTb2xhclZvcmxhdWZ8RFVNTVl8MzcuMHxzdGF0ZXwzNy4wfMKnMjAxNy0wMi0xNyAyMjoxMTozNnxTcGVpY2hlckE1fERVTU1ZfDMxLjd8c3RhdGV8MzEuN3zCpzIwMTctMDItMTcgMjI6MTE6MzZ8VGhlcm1lUnVlY2tsYXVmVGVtcElzdHxEVU1NWXwzMS42fHN0YXRlfDMxLjZ8wqcyMDE3LTAyLTE3IDIyOjExOjM2fFRoZXJtZVZvcmxhdWZUZW1wSXN0fERVTU1ZfDQ3LjZ8c3RhdGV8NDcuNnzCpzIwMTctMDItMTcgMjI6MTE6MzZ8U3BlaWNoZXJBMnxEVU1NWXw1My40fHN0YXRlfDUzLjR8wqcyMDE3LTAyLTE3IDIyOjExOjM4fFRoZXJtZVNwZWljaGVyVGVtcHxEVU1NWXw3NC44fHN0YXRlfDc0Ljh8wqcyMDE3LTAyLTE3IDIyOjExOjQ0fEhLVm9ybGF1ZlZhbHVlfERVTU1ZfDM0LjV8c3RhdGV8MzQuNXzCpzIwMTctMDItMTcgMjI6MTE6NDV8SE1MQU4xfEhNTEFOfGxvYWRMdmw6IGxvd3xsb2FkTHZsfGxvd3zCpzIwMTctMDItMTcgMjI6MTE6NDZ8S29sbGVrdG9yVmFsdWVEYWNoMXxEVU1NWXwxNTF8c3RhdGV8MTUxfMKnMjAxNy0wMi0xNyAyMjoxMTo0NnxLb2xsZWt0b3JEYWNoMXxEVU1NWXw2LjR8c3RhdGV8Ni40fMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxUaGVybWVTcGVpY2hlclRlbXB8RFVNTVl8NzQuOXxzdGF0ZXw3NC45fMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxUaGVybWVWb3JsYXVmVGVtcElzdHxEVU1NWXw0OC4yfHN0YXRlfDQ4LjJ8wqcyMDE3LTAyLTE3IDIyOjExOjUwfFNvbGFyTGVpc3R1bmd8RFVNTVl8MHxzdGF0ZXwwfMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxTb2xhclZvcmxhdWZ8RFVNTVl8MzcuMXxzdGF0ZXwzNy4xfMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxTcGVpY2hlckEyfERVTU1ZfDUzLjN8c3RhdGV8NTMuM3zCpzIwMTctMDItMTcgMjI6MTE6NTB8U3BlaWNoZXJBM3xEVU1NWXw0NC40fHN0YXRlfDQ0LjR8wqcyMDE3LTAyLTE3IDIyOjExOjUwfFNwZWljaGVyQTR8RFVNTVl8MzMuMHxzdGF0ZXwzMy4wfMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxUaGVybWVSdWVja2xhdWZUZW1wSXN0fERVTU1ZfDMxLjV8c3RhdGV8MzEuNXzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18YWN0dWF0b3I6IDB8YWN0dWF0b3J8MHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18YmF0dGVyeTogb2t8YmF0dGVyeXxva3zCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18YmF0dGVyeUxldmVsOiAyLjl8YmF0dGVyeUxldmVsfDIuOXzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18ZGVzaXJlZC10ZW1wOiAxOS4wfGRlc2lyZWQtdGVtcHwxOS4wfMKnMjAxNy0wMi0xNyAyMjoxMTo1MXxPR19FWl9UaGVybW9zdGF0X0VafENVTF9ITXxtZWFzdXJlZC10ZW1wOiAyMy4wfG1lYXN1cmVkLXRlbXB8MjMuMHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18bW90b3JFcnI6IG9rfG1vdG9yRXJyfG9rfMKnMjAxNy0wMi0xNyAyMjoxMTo1MXxPR19FWl9UaGVybW9zdGF0X0VaX0NsaW1hfENVTF9ITXxWYWx2ZVBvc2l0aW9uOiAwfFZhbHZlUG9zaXRpb258MHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWl9XZWF0aGVyfENVTF9ITXxtZWFzdXJlZC10ZW1wOiAyMy4wfG1lYXN1cmVkLXRlbXB8MjMuMHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWl9XZWF0aGVyfENVTF9ITXwyMy4wfHN0YXRlfDIzLjB8wqcyMDE3LTAyLTE3IDIyOjExOjU0fEhLVm9ybGF1ZlZhbHVlfERVTU1ZfDM0LjN8c3RhdGV8MzQuM3zCpzIwMTctMDItMTcgMjI6MTE6NTh8VGhlcm1lU3BlaWNoZXJUZW1wfERVTU1ZfDc0Ljh8c3RhdGV8NzQuOHzCpzIwMTctMDItMTcgMjI6MTE6NTh8VGhlcm1lVm9ybGF1ZlZhbHVlfERVTU1ZfC01LjB8c3RhdGV8LTUuMHzCpzIwMTctMDItMTcgMjI6MTI6MDF8VGhlcm1lUnVlY2tsYXVmVGVtcElzdHxEVU1NWXwzMS40fHN0YXRlfDMxLjR8wqcyMDE3LTAyLTE3IDIyOjEyOjAxfFRoZXJtZVZvcmxhdWZUZW1wSXN0fERVTU1ZfDQ4Ljh8c3RhdGV8NDguOHzCpzIwMTctMDItMTcgMjI6MTI6MDJ8V1dTcGVpY2hlclRlbXAyfERVTU1ZfDQ2LjR8c3RhdGV8NDYuNHzCpzIwMTctMDItMTcgMjI6MTI6MDJ8U3BlaWNoZXJBM3xEVU1NWXw0My41fHN0YXRlfDQzLjV8wqcyMDE3LTAyLTE3IDIyOjEyOjA0fEhLVm9ybGF1ZlZhbHVlfERVTU1ZfDM0LjF8c3RhdGV8MzQuMXw= 
       bc_pid     24327 
       finishFn   DbLog_PushAsyncDone 
       fn         DbLog_PushAsync 
       pid        WAITING: 
       timeout    120 
       Abortarg: 
   Helper: 
     Dblog: 
       Cacheusage: 
         Mydblog: 
           TIME       1486638532.49027 
           VALUE      31 
       Dbi connect('database=fhem;host=localhost;port=3306','fhem',...) failed: 
         Mydblog: 
           TIME       1487405892.98586 
           VALUE      Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1151. 

       Background_processing_time: 
         Mydblog: 
           TIME       1486638160.74013 
           VALUE      0.4276 
       Countcurrent: 
         Mydblog: 
           TIME       1486632305.14062 
           VALUE      1248 
       Counthistory: 
         Mydblog: 
           TIME       1486632305.01294 
           VALUE      98182987 
       Notify_processing_time: 
         Mydblog: 
           TIME       1486638157.98433 
           VALUE      0.0027 
       Sql_processing_time: 
         Mydblog: 
           TIME       1486638160.74013 
           VALUE      0.4174 
       State: 
         Mydblog: 
           TIME       1487406193.56428 
           VALUE      Commit already running - resync at NextSync 
   Readings: 
     2017-02-18 09:23:13   CacheUsage      96629 
     2017-02-18 09:23:13   NextSync        2017-02-18 09:23:43 or if CacheUsage 1000 reached 
     2017-02-09 10:25:05   countCurrent    1248 
     2017-02-09 10:25:05   countHistory    98182987 
     2017-02-18 09:23:13   state           Commit already running - resync at NextSync 
   Cache: 
     index      980599 
     Memcache: 
       883971     2017-02-17 22:12:18|ThermeKesselTempIst|DUMMY|34.0|state|34.0| 
       .
       .
       .
       980598     2017-02-18 09:23:13|ThermeSpeicherTemp|DUMMY|74.9|state|74.9| 
       980599     2017-02-18 09:23:13|myDbLog|DBLOG|Commit already running - resync at NextSync|state|Commit already running - resync at NextSync| 
Attributes: 
   DbLogExclude CacheUsage 
   DbLogType  Current/History 
   asyncMode  1 
   cacheEvents 1 
   cacheLimit 1000 
   shutdownWait 120 
   syncInterval 30

Kann ich die Datensätze noch retten?
Und wo liegt das eigentliche Problem?
Mit HeidiSQL kann ich mich Problemlos auf den Server verbinden.

Vielen Dank und liebe Grüße
Eddy

JoeALLb · 18 Februar 2017, 09:46:20

Kannst du im MySQL-Log herausfinden, warum das commit nicht funktioniert?
Ansonsten musst du wohl ein rollback in kauf nehmen, dadurch verlierst du wohl die 1000 Datensätze dieses commits.

Die Memcache-Daten solltest du retten können, indem Du set <device> reopen 10; eingibst.
Dadurch wird die Verbindung für 10 Sekunden geschlossen und neu aufgebaut.
Die Daten werden dann versucht nochmal zu schreiben... aber ob das funktioniert hängt wieder von der Fehlermeldung aus MySQL ab. (Es könnte ja die Platte voll sein, etc...)

sG
Joe

Edit: Dies bestärkt mich in meinem Wunsch nach einem Speichermodus ohne Transaktion. Diese ist hier in dieser Konstellation nicht hilfreich und kostet Systemressourcen; Ein Rollback bei einer Logdatei macht keinen Sinn.
Edit2: Sorry, die Connect-Fehlermeldung habe ich glatt überlesen. Heikos Antwort unten ist natürlich die bessere!

DS_Starter · 18 Februar 2017, 10:07:15

@est,

Zitat
Dbi connect('database=fhem;host=localhost;port=3306','fhem',...) failed:
Mydblog:
TIME 1487405892.98586
VALUE Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1151.

Möglicherweise hilft auch ein Restart der MySQL mit

Code Auswählen

/etc/init.d/mysqld restart

Der Cache bleibt solange erhalten und wird dann weggeschrieben wenn die Verbindung wieder hergestellt werden kann.

est · 18 Februar 2017, 10:22:02

SHOW FULL PROCESSLIST zeigt mir nur die Session vom Laptop von dem ich es aufrufe.
Ich hatte den MySQL schon neu gestartet. Hat sich aber nichts geändert.

Protokoll aus /var/log/mysql/error.log:

Code Auswählen

170218  9:18:06 [Note] /usr/sbin/mysqld: Normal shutdown

170218  9:18:06 [Note] Event Scheduler: Purging the queue. 0 events
170218  9:18:08 [Warning] /usr/sbin/mysqld: Forcing close of thread 171415  user: 'steier'

170218  9:18:08  InnoDB: Starting shutdown...
170218  9:18:10  InnoDB: Shutdown completed; log sequence number 1762443238810
170218  9:18:10 [Note] /usr/sbin/mysqld: Shutdown complete

170218  9:18:11 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
170218  9:18:11 [Note] Plugin 'FEDERATED' is disabled.
170218  9:18:11 InnoDB: The InnoDB memory heap is disabled
170218  9:18:11 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170218  9:18:11 InnoDB: Compressed tables use zlib 1.2.8
170218  9:18:11 InnoDB: Using Linux native AIO
170218  9:18:11 InnoDB: Initializing buffer pool, size = 128.0M
170218  9:18:11 InnoDB: Completed initialization of buffer pool
170218  9:18:11 InnoDB: highest supported file format is Barracuda.
170218  9:18:13  InnoDB: Waiting for the background threads to start
170218  9:18:14 InnoDB: 5.5.54 started; log sequence number 1762443238810
170218  9:18:14 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
170218  9:18:14 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
170218  9:18:14 [Note] Server socket created on IP: '0.0.0.0'.
170218  9:18:14 [Note] Event Scheduler: Loaded 0 events
170218  9:18:14 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.54-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

Ich kann mich auch von HeidiSQL und von der Konsol über mysql -ufhem -p Problemlos verbinden.
Nächster Schritt wäre dann

Code Auswählen

set <device> reopen 10?

DS_Starter · 18 Februar 2017, 10:31:26

Ja, probiers mal.
Sonst habe ich evtl. noch eine weitere Idee ...

JoeALLb · 18 Februar 2017, 10:33:18

Anbei noch ein Grund, warum ich mir eine valueFormat -Funktion, ähnlich wie bei readingsGroup wünsche.

So wird bei mir aktuell eine Whatsapp-Nachricht geloggt. Mit ist bewußt, dass hier eine Implementierung von SplitFN im Modul
die korrekte lösung wäre, der Modulautor ist daran aber im Moment nicht interessiert.

Code Auswählen

+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
| TIMESTAMP           | DEVICE      | TYPE   | EVENT                                    | READING   | VALUE         | UNIT         | count(*) |
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
| 2016-12-19 14:30:02 | whats | YOWSUP | chatstate: composing                           | chatstate | composing     |              |      256 |
| 2016-12-19 14:31:34 | whats | YOWSUP | chatstate: paused                              | chatstate | paused        |              |       56 |
| 2016-12-19 14:28:40 | whats | YOWSUP | chatstate: received from: 491XXXXX             | chatstate | received from | 491XXXXX     |      131 |
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+

in userReadings könnte ich es in etwa mit diesem Code korrigieren:

Code Auswählen


attr <device> valueFormat 
{
   if( $DEVICE eq "whats" && $VALUE  =~ /^received from/ ) {  $READING=$VALUE;  $VALUE = $UNIT;  }
   elsif( $DEVICE eq "whats" && $VALUE  =~ /^composing/ ) {    $VALUE =  undef; # don't save it to database!}   
}

DS_Starter · 18 Februar 2017, 10:42:33

Morgen Joe,

ich werde mal schauen wie wir so etwas implementieren können.
Allerdings wird es bei mir etwas dauern. Ich möchte erst einmal den gegenwärtigen Stand eingecheckt haben wenn es nach einer entsprechenden Testzeit keine Einwände gibt.
Und dann muss ich mich mal um DbRep kümmern damit die dortigen Insertroutinen ebenfalls PK supporten können. Das klappt ja momentan noch nicht.

Vielleicht hat Dan etwas Zeit um sich darum Gedanken machen zu können. Schön wäre eine solche Funktion schon.

Grüße
Heiko