Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

DS_Starter

#795
Morgen Joe,

kann ich momentan noch nicht nachvollziehen, weil es 1. bei mir nicht passiert und 2. ich an dieser Funktion schon ewig nichts geändert habe.

Geh doch mal bitte in das aktuelle Modul und ändere das Timeout $to in Zeile 1336 auf einen höheren Wert:

sub DbRep_firstconnect($) {
  my ($hash) = @_;
  my $name       = $hash->{NAME};
  my $to         = "120";


Der ist auf 2 Minuten eingestellt. Das ist schon sehr lange. Kann es sein dass deine DB nicht erreichbar ist zu diesem Zeitpunkt ?.
Aber trotzdem darf FHEM nicht blockieren, da es ja ein blockingCall ist.
Bisschen undurchsichtig gerade.

LG,
Heiko
ESXi@NUC+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

JoeALLb

Hallo Heiko,

habe fast befürchtet, dass es "undurchsichtig" ist, jedoch gab das Log leider nicht mehr her und es war reproduzierbar.
Jetzt allerding funktioniert es wieder ganz normal. Meine DB war eigentlich nicht ausgelastet und ist relativ performant!

Jedoch sind jetzt auch die Timeout-Meldungen von DbRep später im Log, also erst, nachdem die Weboberfläche verfügbar ist.

Sieh mal wie lange dieser Test hier durchgeführt wird:

2018.09.19 10:48:51 3: DbRep rep.samplefill - Connectiontest to database mysql:database=fhem;mysql_socket=/var/run/mysqld/mysqld.sock with user fhemuser
2018.09.19 10:49:34 4: DbRep rep.samplefill - Connectiontest to db mysql:database=fhem;mysql_socket=/var/run/mysqld/mysqld.sock successful


Wobei eine normale Abfrage mit Connectionaufbau sehr schnell am System geht:

time echo "select * from history limit 1;" | mysql -pXXXX fhem
TIMESTAMP       DEVICE  TYPE    EVENT   READING VALUE   UNIT    datatype
2018-01-09 10:49:36     sql     DBLOG   CacheUsage: 0   CacheUsage      0               0

real    0m0,029s
user    0m0,016s
sys     0m0,012s


Hilft das irgendwie weiter?

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

DS_Starter

So richtig kann ich mir noch keinen Reim machen. Der Test darf ruhig etwas länger dauern, es wird der kleinste Timestamp innerhalb der DB ermittelt.
Das passiert aber eben auch in einem blockingCall und darf deshalb keine Auswirkunge auf FHEM haben. Hat es bei mir auch nicht.
Kann es sein, dass die Definition des DbRep-Devices in der fhem.cfg vor der Definition des DbLog-Devices passiert ?
Wobei dann eigentlich Fehler kommen müssten ....
ESXi@NUC+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

DS_Starter

#798
Hallo Joe,

habe soeben eine geänderte Version von DbRep eingecheckt.
Die Ermittlung des kleinsten Timestamp in der DB geht nun deutlich schneller (habe dein statement verwendet).
Außerdem wird ein eventuell gefundener invalider Timestamp im state angezeigt:


invalid timestamp "0000-00-00 00:00:00" found in database - please delete it


Das kann z.B. vorkommmen falls die DB älter ist und Altlasten enthält die damals noch nicht abgefangen wurden.

LG,
Heiko
ESXi@NUC+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

JoeALLb

Hallo Heiko,

Danke, damit bekomme ich die Fehlermeldunge nicht mehr.
Was ich aber nicht ganz verstehe ist:

DbRep ist konzipiert, dass man mehrere Devices für verschiedene Aufgaben anlegt. Ich habe 18 solche Devices, die alle meistens nichts zu tun haben,
da ich nur einmal im Quartal meine DB bereinige.
Wenn ich es korrekt sehe, greifen jedoch zumindest beim FHEM-Start alle 18 Devices auf die Datenbank zu und machen dort eine Abfrage um danach auf den Status "connected" zu springen. Ist das korrekt? Wenn ich also zB die Anzahl der gleichzeitigen Connections auf 3 reduziere, könnte es hier zu "stau" kommen?!.

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

DS_Starter

Hi Joe,

ich habe sogar 112 Devices in meinem Prod ....  ;)

Du hast richtig beobachtet, dass beim Start jedes Device einen kurzen connect zur DB macht. Brauche ich um bestimmte Infos zu holen.
Aber wenn du genau hinschaust wirst du sehen, dass die Devices nicht alle gleichzeitig in die Db greifen und der Status connected nach und nach bei allen Devices eintritt.
Im Modul habe ich dafür die Aufrufe nach dem Zufallsprinzip innerhalb einer von mir definierten Zeit organisiert. Die Gefahr eines gleichzeitigen Aufrufs ist dadurch gering, wenn auch nicht unmöglich.
Du wirst wahrscheinlich kein Problem bekommen, wenn du die Anzahl der gleichzeitigen db- connects begrenzt. Aber ich würde in dem Fall auch die Anzahl der möglichen gleichzeitigen Blockingcalls im fhem begrenzen. Dann dürfte es kein spürbares Problem geben.

Lg,
Heiko
ESXi@NUC+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

JoeALLb

Zitat von: DS_Starter am 24 September 2018, 15:15:03
Aber ich würde in dem Fall auch die Anzahl der möglichen gleichzeitigen Blockingcalls im fhem begrenzen. Dann dürfte es kein spürbares Problem geben.

Hallo Heiko,

danke für den Tip! das werde ich mal beobachten!!!

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

oldscout

Hallo,
seit kurzem, leider weiss ich nicht seit wann, weil ich nur sporadisch dort reinschaue, zählt dbrep (Count) nicht mehr richtig.
Die Definition ohne Attribut "timeOlderThan" ist noch ok, der Zähler stimmt. Setze ich das Attribut auf nur "1", wird nur ein Bruchteil aus der DB gezählt.
Also zb. ohne sind es 115000 Datensätze, mit nur noch 290. Timestamps sind aber ok, lt. SQL-Manager.
Ich bitte mal den Entwickler, sich das anzuschauen. Ich bereinige damit die Datenbank.
Danke.
FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

DS_Starter

Hast du die aktuellste Version ?

Ich habe das versucht bei mir nachzustellen, funktioniert aber einwandfrei:


2018.10.09 19:35:56.121 4: DbRep Rep.CPU - -------- New selection ---------
2018.10.09 19:35:56.121 4: DbRep Rep.CPU - Command: countEntries history
2018.10.09 19:35:56.122 4: DbRep Rep.CPU - Timestamp begin human readable: 2016-04-10 07:00:00
2018.10.09 19:35:56.122 4: DbRep Rep.CPU - Time difference to current time for calculating Timestamp end: 1 sec
2018.10.09 19:35:56.123 4: DbRep Rep.CPU - Timestamp end human readable: 2018-10-09 19:35:55
2018.10.09 19:35:56.123 4: DbRep Rep.CPU - Aggregation: no
2018.10.09 19:35:56.137 4: DbRep Rep.CPU - SQL execute: SELECT COUNT(*) FROM history where DEVICE = 'sysmon' AND READING = 'stat_cpu_percent' AND TIMESTAMP >= '2016-04-10 07:00:00' AND TIMESTAMP <= '2018-10-09 19:35:55' ;


Setze dir bitte verbose 4 und poste mal den Logausschnitt und auch den List deines DbRep.

Grüße,
Heiko
ESXi@NUC+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

oldscout

Hallo,
die Version ist aktuell von gestern, hier das Log:
018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - -------- New selection ---------
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Command: countEntries history
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Timestamp begin human readable: 2018-10-06 18:51:10
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Time difference to current time for calculating Timestamp end: 86400 sec
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Timestamp end human readable: 2018-10-09 07:05:29
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Aggregation: no
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - SQL execute: SELECT COUNT(*) FROM history where DEVICE = 'var_Z1' AND TIMESTAMP >= '2018-10-06 18:51:10' AND TIMESTAMP <= '2018-10-09 07:05:29' ;


und hier die DEF:

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        myDbLog
   LASTCMD    countEntries history
   MODEL      Client
   NAME       db_g8_var_Z1
   NOTIFYDEV  global,db_g8_var_Z1
   NR         627
   NTFY_ORDER 50-db_g8_var_Z1
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   VERSION    8.2.1
   HELPER:
     DBLOGDEVICE myDbLog
     MINTS      2018-10-06 18:51:10
     RDPFDEL    .*
     SQLHIST   
     CV:
       aggregation no
       aggsec     1
       destr      2018-10-09
       dsstr      2018-10-06
       epoch_seconds_end 1539061529.34278
       mestr      10
       msstr      10
       testr      07:05:29
       tsstr      18:51:10
       wdadd      172800
       yestr      2018
       ysstr      2018
   READINGS:
     2018-10-10 07:05:29   2018-10-06__var_Z1__/__COUNT_history__no_aggregation 1455
     2018-10-10 06:59:12   __var_Z1__/__COUNT_history__no_aggregation 115242
     2018-10-10 07:05:29   state           done
     2018-10-10 07:05:29   timeOlderThan_days 1
   dbloghash:
     CFGFN     
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION /etc/fhem/db.conf
     DEF        /etc/fhem/db.conf .*:.*
     MODE       synchronous
     MODEL      MYSQL
     NAME       myDbLog
     NR         52
     NTFY_ORDER 50-myDbLog
     PID        11514
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     UTF8       0
     VERSION    3.12.2
     dbconn     mysql:database=fhem;host=192.168.1.212;port=3306
     dbuser     fhemuser
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     Helper:
       DBLOG:
         countCurrent:
           myDbLog:
             TIME       1539122581.47579
             VALUE      1089
         countHistory:
           myDbLog:
             TIME       1539122581.42609
             VALUE      1639384
         state:
           myDbLog:
             TIME       1539104596.32857
             VALUE      connected
     READINGS:
       2018-10-10 00:03:01   countCurrent    1089
       2018-10-10 00:03:01   countHistory    1639384
       2018-07-21 00:03:40   lastRowsDeleted 87785
       2018-10-10 07:07:42   state           connected
     cache:
       index      0
Attributes:
   DbLogExclude .*
   allowDeletion 0
   device     var_Z1
   group      DB-Delete-G8
   readingPreventFromDel .*
   room       50-DBRep
   timeOlderThan 86400
   userReadings timeOlderThan_days {AttrVal($NAME,"timeOlderThan","0") / 3600 / 24 ;}
   userattr   dbRepDel
   verbose    4


Das userattr dbRepDel ist aktuell noch nicht belegt.....
Was ich gerade bemerke:  Das Reading zählt(?)  vom 6.10.18, an diesem Tag habe ich das Device angelegt.... Die ältesten Einträge in der DB sind vom März 2018...
Danke.
FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

DS_Starter

#805
Das sieht doch erstmal völlig in Ordnung aus. Es werden über 1Mio Einträge gezählt.
EDIT: habe gerade gesehen dass diese Zahl der Wert aus dblog ist.

Das die Selektion am 06.10. beginnt liegt daran, dass beim Start der älteste in der DB vorhandene Datensatz ermittelt wird. Und der ist augenscheinlich mit dem Timestamp MINTS = 2018-10-06 18:51:10.


   HELPER:
     DBLOGDEVICE myDbLog
     MINTS      2018-10-06 18:51:10


Führe mal bitte ein "get ... minTimestamp" aus. Was zeigt dann das Reading "timestamp_oldest_dataset" ?
ESXi@NUC+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

DS_Starter

#806
Und bitte auch noch ausführen


set dbrep sqlCmd select TIMESTAMP from history order by TIMESTAMP limit 1;


was steht dann im Reading SqlResultRow_1?

Grüße,
Heiko
ESXi@NUC+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

JoeALLb

Wurden die Timestamp-Werte nachträglich bearbeitet, oder ggf. später welche importiert?
In diesem Fall kann eine Abfrage ohne "order by", also nur
set dbrep sqlCmd select TIMESTAMP from history limit 1;
ein anderes Ergebnis liefern.

Bleibt also die Entscheidung, ob man die Datenbank nach einem Ändern mal "neu sortiert" und
die schnelle Abfrage
select TIMESTAMP from history limit 1; belässt oder eben die sichere Abfrage
mit "order by" nimmt..


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

DS_Starter

Hi Joe,

ich tendiere dazu order by mit hinzuzufügen.
Warten wir die Info von oldscout mal ab, es ist der erste Fall dieser Art.
Aber meine Vermutung ging auch in die von dir beschriebenen e Richtung.

Lg
Heiko
ESXi@NUC+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

DS_Starter

Bin jetzt schon mal prophylaktisch auf die sichere Seite gewechselt und habe im Modul die Abfrage um "order by" ergänzt.
Das ist sicherer und vermeidet proaktiv Probleme, unabhängig davon was oldscout  noch berichten wird.

Grüße
Heiko
ESXi@NUC+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