Autor Thema: 93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)  (Gelesen 5702 mal)

Offline JoeALLb

  • Sr. Member
  • ****
  • Beiträge: 946
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #195 am: 17 März 2017, 13:06:26 »
Wenn ich dich richtig verstanden habe, soll der Befehl exportCache nur den Inhalt des Caches in eine beliebige Textdatei an beliebiger Stelle schreiben können (optional mit löschen des Caches danach) damit man die Daten im Disasterfall (wie bei dir) nicht verliert sondern hinterher, wenn man  seine DB verfügbar hat, wieder importieren kann. Habe ich das so richtig zusammengefasst ?

Perfekt, genau so sind meine Überlegungen... Ich wußte einfach nicht wie groß der Cache werden kann/darf, weshalb ich ihn bei dieser Größe leeren wollte.
Natürlich habe ich auch überlegt, kurzfristig auf sqlite zu wechseln, da dies aber nicht ohne ein redefine des moduls geht, hab ich davon die finger gelassen....
Wenn der Config-String als Attribut möglich wäre, wäre das vermutlich auch eine Option gewesen...  aber durch ein redefine des DbLog-Devices hätte ich (vermutlich) den Cache komplett verloren...

sG
Joe
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #196 am: 17 März 2017, 13:13:42 »
Zitat
Natürlich habe ich auch überlegt, kurzfristig auf sqlite zu wechseln, da dies aber nicht ohne ein redefine des moduls geht, hab ich davon die finger gelassen....

Hättest du IMHO mal probieren können. Modul so lassen, nur die Config-Datei entsprechend ändern und ein "rereadcfg" machen. Sollte klappen und den Cache auch nicht in Mitleidenschaft ziehen.

Deinen Wunsch will ich mal versuchen umzusetzen. WE wird verregnet  ;)
Mal schauen wie ich Zeit habe.

Grüße
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline Pyromane

  • Full Member
  • ***
  • Beiträge: 129
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #197 am: 17 März 2017, 15:14:39 »
Hallo,

ich bin mir nicht ganz sicher ob ich hier im Thread richtig bin, aber ich habe nach einigen Tagen wieder mal in meine Testinstallation (sqlite) reingeschaut und ein update angestoßen:
Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/db.conf
   DBMODEL    SQLITE
   DEF        /opt/fhem/db.conf .*:.*
   MODE       asynchronous
   NAME       myDbLog
   NR         19
   NTFY_ORDER 50-myDbLog
   PID        1508
   REGEXP     .*:.*
   STATE      DBD::SQLite::st execute_array failed: executing 47 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
, 0
   TYPE       DbLog
   VERSION    2.13.5
   dbconn     SQLite:dbname=/opt/fhem/fhem.db
   dbuser
   Helper:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
   Helper:
     Dblog:
       Countcurrent:
         Mydblog:
           TIME       1489759165.21155
           VALUE      47
   Readings:
     2017-03-17 15:00:37   CacheUsage      47
     2017-03-17 15:00:37   NextSync        2017-03-17 15:01:07 or if CacheUsage 500 reached
     2017-03-17 14:59:25   countCurrent    47
     2017-03-16 03:19:24   countHistory    702538
     2016-12-31 00:05:28   lastRowsDeleted 22663
     2017-03-17 15:00:37   state           DBD::SQLite::st execute_array failed: executing 47 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
, 0
     2017-02-26 12:23:04   userCommand     DELETE FROM history WHERE device = 'ESPEasy_ESPTest_System' AND TIMESTAMP < datetime(1487848063, 'unixepoch');
     2016-08-07 18:58:03   userCommandResult 2016-08-07
   Cache:
     index      152
     Memcache:
       106        2017-03-17 14:59:59|mySysMon|SYSMON|ram: Total: 181.38 MB, Used: 80.70 MB, 44.49 %, Free: 100.68 MB|ram|Total: 181.38 MB, Used: 80.70 MB, 44.49 %, Free: 100.68 MB|
       107        2017-03-17 15:00:04|MyBroker|MQTT|connection: active|connection|active|
       108        2017-03-17 15:00:11|ESPEasy_ESPTest_System|ESPEASY|rssi: -91|rssi|-91|
       109        2017-03-17 15:00:11|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -91 upt: 188622|ram|25328 rss: -91 upt: 188622|
       110        2017-03-17 15:00:28|ESPEasy_ESPTest_System|ESPEASY|upt: 188623|upt|188623|
       111        2017-03-17 15:00:28|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -91 upt: 188623|ram|25328 rss: -91 upt: 188623|
       112        2017-03-17 14:59:07|MyBroker|MQTT|connection: connected|connection|connected|
       113        2017-03-17 14:59:28|ESPEasy_ESPTest_System|ESPEASY|upt: 188622|upt|188622|
       114        2017-03-17 14:59:28|ESPEasy_ESPTest_System|ESPEASY|ram: 25144 rss: -90 upt: 188622|ram|25144 rss: -90 upt: 188622|
       115        2017-03-17 14:59:34|ESPEasy_ESPTest_System|ESPEASY|ram: 25328|ram|25328|
       116        2017-03-17 14:59:34|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -90 upt: 188622|ram|25328 rss: -90 upt: 188622|
       117        2017-03-17 14:59:35|Blume2|XIAOMIFLOWERSENS|active|state|active|
       118        2017-03-17 14:59:35|Blume2|XIAOMIFLOWERSENS|call data|state|call data|
       119        2017-03-17 14:59:07|MyBroker|MQTT|connection: active|connection|active|
       120        2017-03-17 14:59:09|ESPEasy_ESPTest_System|ESPEASY|ram: 25144|ram|25144|
       121        2017-03-17 14:59:09|ESPEasy_ESPTest_System|ESPEASY|ram: 25144|ram|25144|
       122        2017-03-17 14:59:11|ESPEasy_ESPTest_System|ESPEASY|rssi: -90|rssi|-90|
       123        2017-03-17 14:59:11|ESPEasy_ESPTest_System|ESPEASY|ram: 25144 rss: -90|ram|25144 rss|-90
       124        2017-03-17 14:59:20|Sys2|MQTT_DEVICE|Uptime: 191479.00|Uptime|191479.00|
       125        2017-03-17 14:59:24|global|GLOBAL|DEFINED telnetForBlockingFn_1489759164|state|DEFINED telnetForBlockingFn_1489759164|
       126        2017-03-17 14:59:25|myDbLog|DBLOG|countCurrent: 47|countCurrent|47|
       127        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|battery: ok|battery|ok|
       128        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|temperature: 25.1|temperature|25.1|°C
       129        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|lux: 2157|lux|2157|
       130        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|moisture: 81|moisture|81|
       131        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|fertility: 1565|fertility|1565|
       132        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|firmware: 2.7.0|firmware|2.7.0|
       133        2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|active|state|active|
       134        2017-03-17 14:59:41|ESPEasy_ESPTest_System|ESPEASY|rssi: -92|rssi|-92|
       135        2017-03-17 14:59:41|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -92 upt: 188622|ram|25328 rss: -92 upt: 188622|
       136        2017-03-17 14:59:48|Blume1|XIAOMIFLOWERSENS|active|state|active|
       137        2017-03-17 14:59:48|Blume1|XIAOMIFLOWERSENS|call data|state|call data|
       138        2017-03-17 14:59:50|Sys2|MQTT_DEVICE|Uptime: 191480.00|Uptime|191480.00|
       139        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|battery: ok|battery|ok|
       140        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|temperature: 25.2|temperature|25.2|°C
       141        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|lux: 6408|lux|6408|
       142        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|moisture: 19|moisture|19|
       143        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|fertility: 1709|fertility|1709|
       144        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|firmware: 2.6.2|firmware|2.6.2|
       145        2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|active|state|active|
       146        2017-03-17 14:59:58|mySysMon|SYSMON|cpu_freq: 700|cpu_freq|700|
       147        2017-03-17 14:59:59|mySysMon|SYSMON|cpu_temp_avg: 51.8|cpu_temp_avg|51.8|
       148        2017-03-17 14:59:59|mySysMon|SYSMON|loadavg: 0.38 0.18 0.16|loadavg|0.38 0.18 0.16|
       149        2017-03-17 14:59:59|mySysMon|SYSMON|cpu_temp: 51.92|cpu_temp|51.92|
       150        2017-03-17 14:59:59|mySysMon|SYSMON|eth0_diff: RX: 0.06 MB, TX: 0.06 MB, Total: 0.12 MB|eth0_diff|RX: 0.06 MB, TX: 0.06 MB, Total: 0.12 MB|
       151        2017-03-17 14:59:59|mySysMon|SYSMON|fs_boot: Total: 60 MB, Used: 20 MB, 34 %, Available: 41 MB at /boot|fs_boot|Total: 60 MB, Used: 20 MB, 34 %, Available: 41 MB at /boot|
       152        2017-03-17 14:59:59|mySysMon|SYSMON|fs_root: Total: 7351 MB, Used: 4631 MB, 67 %, Available: 2367 MB at /|fs_root|Total: 7351 MB, Used: 4631 MB, 67 %, Available: 2367 MB at /|
Attributes:
   DbLogType  History
   asyncMode  1
   verbose    5
2017.03.17 15:02:38 2: DbLog myDbLog -> Error table history - DBD::SQLite::st execute_array failed: executing 77 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.

2017.03.17 15:02:38 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.03.17 15:02:38 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.03.17 15:02:38 4: DbLog myDbLog -> ################################################################
2017.03.17 15:02:38 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2017.03.17 15:02:38 4: DbLog myDbLog -> ################################################################
2017.03.17 15:02:38 4: DbLog myDbLog -> amount of events received: 1 for device: myDbLog
2017.03.17 15:02:38 4: DbLog myDbLog -> check Device: myDbLog , Event: DBD::SQLite::st execute_array failed: executing 77 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
, 0
2017.03.17 15:02:38 5: DbLog myDbLog -> DbLog_PushAsyncDone finished

Grüße
Pyro

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #198 am: 17 März 2017, 15:41:49 »
Hallo Pyro,

der Prozess kann auf deine DB (bzw. Tabelle) nicht zugreifen. Bei mir kommt das (nur bei SQLite) immer mal wieder vor wenn ich die DB mal mit einem externen SQL-Editor geöffnet hatte.
Üblicherweise hilft ein "reopen" um den Zustand dann wieder zu beseitigen. Möglicherweise hängt noch ein anderer Prozess auf deiner DB.
Nebenbei ... da du mit ".*:.* " arbeitest und alles logst was so an events kommt, würde ich mit excludeDevs zumindest das eigene Logdevice myDbLog davon ausschließen.

Grüße
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline Pyromane

  • Full Member
  • ***
  • Beiträge: 129
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #199 am: 17 März 2017, 18:32:23 »
Nabend Heiko,

danke für den Hinweis bezüglich meines großzügigen Loggings, aber beim Testsystem ist es gewollt.

Das Problem konnte ich inzwischen auch beheben, die Datenbank war beschädigt und konnte durch ein umkopieren wiederhergestellt  werden. Falls jemand mal in einer ähnlichen Situation ist, hier die notwendigen Befehle:
sudo sqlite3 /opt/fhem/fhem.db ".dump" | sudo sqlite3 /opt/fhem/fhem2.db
sudo chown -c fhem /opt/fhem/fhem2.db
Danach entweder die db.conf anpassen oder die beschädigte Datenbankdatei löschen und fhem2.db in fhem.db umbenennen.

Offline jnewton957

  • Full Member
  • ***
  • Beiträge: 291
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #200 am: 17 März 2017, 20:15:44 »
Hallo,

in Bezug auf Optimierung habe ich da eine Frage.

Ich habe dblog eingerichtet gem. Wiki.
Also in "/opt/fhem/fhem.db"

Nun möchte die die Belastung meiner SD Karte reduzieren. (gebranntes Kind:-) )

Ich möchte daher die Datenbank auf den USB Stick auslagern.

Ich hätte kein Problem damit die Datenbank neu anzulegen: sudo sqlite3 /media/usbstick/DB/fhem.db

Ist es sinnvoll, die Datenbank auf den USB Stick umzuziehen ?

Soll ich die DB auf dem USB Stick NEU anlegen und dann in der db.conf den Eintrag "/media/usbstick/DB/fhem.db" machen oder mit einem symbolischen link arbeiten ?

Was ist der sinnvollste Weg ?

Danke für die Infos
Jörg
FHEM5.7 auf Pi2
V 1.65 nanoCUL433 (IT)
nanoCUL JeeLink
V 1.66 nanoCUL868 (HM) (ESA2000WZ)
xELRO AB440, xDECT200, PCA301, xTFA30.3125,  HM, TabletUI, IR-Schreiblesekopf (Udo)

Offline JoeALLb

  • Sr. Member
  • ****
  • Beiträge: 946
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #201 am: 17 März 2017, 21:54:42 »
Hallo Jörg,

mit SqLite weiß ich es leide rnicht genau, meine DB war damals manchmal corrupt, weshalb ich auf MySQL/MariaDB umgestiegen bin.
Seit 4 Jahren läuft das auf ein paar RPIS eigentlich problemlos, ich nutze gute! SD-Karten und nutze bei den Datenbanken Partitionen, dass die Daten auf mehrere Dateien aufgeteilt werden.
wie gesagt, bisher ohne korrupion und bei guter Geschwindigkeit.
Und der neue ASYNC-Modus trägt ebenfalls dazu bei, dass die Daten seltener geschrieben werden....

Auf einen USB-Stick mache ich tägliche Backups. Habe jedoch festgestellt, dass der USB.Stick mein Booten für mySQL regelmäßig zu spät gemouted wird, musste dafür eine Pause im Startscript einbauen.

Ich hoffe, dass meine Erfahrung Dir ein bisschen helfen konnte ;-)

Grüße
Joe
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Offline Omega

  • Full Member
  • ***
  • Beiträge: 356
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #202 am: 18 März 2017, 14:51:18 »
Frage zum asyncMode:
In der Commandref steht unter attr asyncMode: "Attribut "timeout" (Default 120s)".
Bei attr timeout steht: " im asynchronen Modus (default 1800s)".
Beobachte ich das Reading NextSync, wechselt das alle 30 Sekunden.

Zeitweise hatte ich attr timeout auf 600 stehen, das hat aber anscheinend (lt. Reading NextSync) nicht gezogen.
Habe ich etwas nicht verstanden oder gibt es da noch einen kleinen Fehler?

LG
Holger
Cubietruck: FHEM 5.7
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
JeeLink: LaCrosse, TFA 30.3144.IT, TX29-IT
ZWave: ZWDongle, Philio PSM02-1 Slim Multi-Sensor

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #203 am: 18 März 2017, 15:12:24 »
Hallo Holger,

den timeout hatte ich früher auf 120s stehen und wegen diverser Hinweise auf default 1800 gesetzt. Ich schau nochmal durch das Modul durch ob ich eine Stelle vergessen habe umzuschreiben.

Aber das ist nur der timeout für den geforkten Hintergrundprozesse im Asynchmode. Das Intervall zum Wegschreiben der Daten in die DB stellst du mit dem Attribut syncInterval ein.

schönes WE
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline Omega

  • Full Member
  • ***
  • Beiträge: 356
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #204 am: 19 März 2017, 09:10:33 »
Hallo Heiko,

danke für die Info - ist schon etwas verwirrend, wenn man nicht im Thema drinsteckt. Aber das mit dem Attribut syncInterval hätte ich auch schon selber lesen können  :-[

LG
Holger
Cubietruck: FHEM 5.7
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
JeeLink: LaCrosse, TFA 30.3144.IT, TX29-IT
ZWave: ZWDongle, Philio PSM02-1 Slim Multi-Sensor

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #205 am: 19 März 2017, 10:39:39 »
Hallo miteienader,

anbei die weiterentwickelte Version 2.14.0.

Was ist neu bzw. verändert ? Hier die Liste:

* neue set-Befehle exportCache und importCachefile sowie neues Attr expimpdir
  Die Befehle dienen zum Export bzw. Import von Cacheinhalten so wie Joe es vergeschlagen hat.
  Der Filename wird fest generiert. Er beginnt mit "cache_" gefolgt von dem DbLog-Namen (z.B. LogDB) und dem
  aktuellen Zeitstamp des Exports. Ich habe es extra fest definiert damit ich für den Import eine schöne Drop-Downliste
  über das Menü anbieten kann (habe bei Dan's Modul gespickelt ;) ).
  Weiterhin werden im Drop-Down Menü nur die zu dem DbLog-Device gehörigen Exportfiles absteigend sortiert angezeigt falls man mehrere DbLog-Devices hat.
  Ist das Attr expimpdir nicht gesetzt, wird automatisch {global}{modpath}/log/ benutzt, d.h. die Exportfiles landen im
  Logverzeichnis.
  Mit dem Attr expimpdir kann man einen (kompletten) Pfad angeben in welchen die Files geschrieben werden sollen.
 
* exportCache kann mit den Optionen nopurge bzw. purgeCache aufgerufen werden. Im letzteren Fall wird der Cache nach dem
  Export geleert ohne in die DB zu schreiben.
 
* die Log-Fehlerausgaben sind erweitert sofern man PK benutzt (nur zur Userinfo warum z.B. Fehler beim Insert auftreten)

* alle cache relevanten set-Befehle (listcache usw.) werden nur noch im Menü angezeigt wenn asynch-Mode benutzt wird
  da sie ja sonst obsolet sind
 
* kleinere Fixes (z.B. timeout 1800s in Doku)
   
Mit dem exportCache könnten sich interessante Einsatzmöglichkeiten ergeben. So könnte man beipielsweise mit einem AT den
Füllstand von CacheUsage abfragen und wenn dieser Wert über dem eingestellten cacheLimit (attr) ist, stimmt irgendwas nicht
man könnte dann den Cache wegschreiben. Durch den Timestamp im Dateinamen kann der Cache regelmäßig weggeschrieben werden. da jeder Schreibvorgang ein neues eindeutiges File generiert.

Die Commandref ergänze ich erst später wenn ihr bei euch auch getestet habt.
Viel Spaß dabei und einen schönen Sonntag.

@Holger, don't worry , dafür gibt's ja den Thread  :)

VG
Heiko
« Letzte Änderung: 19 März 2017, 12:01:33 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline JoeALLb

  • Sr. Member
  • ****
  • Beiträge: 946
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #206 am: 19 März 2017, 14:35:38 »
@Heiko: Vielen Dank, dass Du das schlechte Wetter für das Modul genutzt hast...

Habe die neuen Funktionen getestet und bisher keine unerwarteten Dinge festgestellt!!
In der Tat gibt uns das viele neue Möglichkeiten, ich frage mich gerade ob man dadurch das Fallback nach SqLite, das mal angedacht war, noch benötigt....
Ich denke, dass damit eigentlich der Sinn davon jetzt schon erledigt ist...
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Offline Omega

  • Full Member
  • ***
  • Beiträge: 356
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #207 am: 22 März 2017, 10:12:39 »
Dblog : die Spaltenlängen zwischen SQLite und MySQL sind unterschiedlich bzw. werden unterschiedlich verwendet.

Ich habe unter SQLite eine DB angelegt mit folgenden Parametern:
CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(64), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(64), UNIT varchar(32));

Definiere ich die Tabelle dann in FHEM, erhalte ich in den Internals
COLUMNS  field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
d.h. wundersamer Weise haben sich die Spaltenlängen bei Device, Type, Reading und Value verdoppelt.

Aufgefallen ist mir das, da ich parallel auch mit MySQL teste. Dort habe ich die Datenbank mit den gleichen Längenangaben angelegt. Und dann festgestellt, dass Readings nach 32 Zeichen abgeschnitten werden, obwohl auch hier lt. den Internals die Werte verdoppelt sind.
COLUMNS  field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32

Unter SQLite sind Readings > 32 Zeichen vorhanden und auch auswertbar, bei MySQL sind sie abgeschnitten (und damit nicht nutzbar).
Schaue ich auf die DB mit „.schema“, sehe ich sie so, wie ich sie oben definiert habe.

Unter SQLite funktioniert folgender select:
select * from history where DEVICE='myElectricityCalculator' AND READING='strombezug_electricityConsumed_kWh_EnergyDay';
Unter MySQL nicht. Der Readingname ist zu lang. Erst wenn ich ihn auf 32 Zeichen kürze ('strombezug_electricityConsumed_k), erhalte ich eine Ausgabe (nur nicht die gewünschte).

Verwirrend.

Wie geht ihr mit dem Problem um? Einfach die MySQL-DB mit größeren Werten anlegen?

LG
Holger

Cubietruck: FHEM 5.7
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
JeeLink: LaCrosse, TFA 30.3144.IT, TX29-IT
ZWave: ZWDongle, Philio PSM02-1 Slim Multi-Sensor

Offline JoeALLb

  • Sr. Member
  • ****
  • Beiträge: 946
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #208 am: 22 März 2017, 13:14:57 »
Mit dem exportCache könnten sich interessante Einsatzmöglichkeiten ergeben. So könnte man beipielsweise mit einem AT den
Füllstand von CacheUsage abfragen und wenn dieser Wert über dem eingestellten cacheLimit (attr) ist, stimmt irgendwas nicht
man könnte dann den Cache wegschreiben. Durch den Timestamp im Dateinamen kann der Cache regelmäßig weggeschrieben werden. da jeder Schreibvorgang ein neues eindeutiges File generiert.

Ich habe dies mal getestet und mit diesem Beispiel scheint das bisher sehr gut zu funktionieren.
define di_sqlWatchdog DOIF ([sql:NextSync] && [?sql:CacheUsage]>1000 && [?sql:sql_processing_time:sec]>3000 && [?sql:state] !~/closed for/)\
 ((msg Achtung, SQL-Fehler $SELF))\
 (set sql exportCache purgecache)
Gleichzeitig lasse ich mir über "msg" eine Nachricht auf das Handy schicken um mich zu informieren, dass die SQL-Datenbank im Moment nicht funktioniert.

Edit1: @Heiko: Schön wäre es noch, wenn ich für das Erstellen eines Exportfiles ein Reading nutzen könnte. Dann wüßte ich mit Sicherheit, wann das letzte Exportfile entstanden ist und ob Handlungsbedarf für mich besteht.
« Letzte Änderung: 22 März 2017, 13:21:06 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1108
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #209 am: 23 März 2017, 00:57:40 »
Hallo Holger,

Zitat
Definiere ich die Tabelle dann in FHEM, erhalte ich in den Internals

COLUMNS  field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32

d.h. wundersamer Weise haben sich die Spaltenlängen bei Device, Type, Reading und Value verdoppelt.

nein, die Werte haben sich nicht verdoppelt. Der Zusammenhang ist etwas anders.
Seit einiger Zeit (letztes Jahr) ist die Standardlänge der Felder "Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32".
Das ist auch so in dem contrib-Verzeichnis  hinterlegt.
DbLog zeigt in den Internals an, mit welchen Feldlängen DbLog zur Zeit arbeitet. Sind Events etc. länger, werden sie auf die angegebenen Längen gekürzt. Du solltest also beim create die Tabellen mindestens mit den Feldlängen wie im Standard angegeben anlegen.

Im DbLog hast du mit Attributen auch die Möglichkeit die Feldlängen mit denen das Modul operiert, zu ändern. Du kannst z.B. event auf "0" setzen, dann wird de facto diese Spalte nicht mehr in die DB geschrieben.

Die andere Sache ...
Zitat
Unter SQLite sind Readings > 32 Zeichen vorhanden und auch auswertbar, bei MySQL sind sie abgeschnitten (und damit nicht nutzbar).
Schaue ich auf die DB mit „.schema“, sehe ich sie so, wie ich sie oben definiert habe.

hat etwas mit den Eigenheiten der DB-Typen zu tun. SQLite speichert trotz der Create-Spaltenbreiten Werte auch dann wenn sie länger sind (sofern sie nicht vom Modul beschnitten werden). MySQL tut das nicht. Ist ein Wert länger als die Feldlänge wid er abgeschnitten und ggf. führt das auch zu entsprechenden Fehlermeldungen. Ich glaube auch dass das diesbezügliche Verhalten durch Parametrisierung in MySQL verändert werden kann.

Ich würde es so machen .... die Feldlängen in MySQL mindestens so wie Standard (siehe oben) oder größer wie du sie brauchst. In dem Fall dann auch die Attribute in DbLog setzen damit das Modul nicht von sich aus beim Standard abschneidet.

Grüße
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

 

decade-submarginal