93_DbLog.pm Fehler?

Begonnen von janus4, 25 Dezember 2014, 19:02:16

Vorheriges Thema - Nächstes Thema

janus4

Hallo,
ich beschäftige mich seit ein paar Wochen mit FEHM und hatte mit meinem Raspberry PI und aktuellstem FHEM (Heute über UPDATE neu geholt) ein Problem mit meiner NAS basierten MySQL Datenbank und der Verwendung von 93_DbLog.pm

Die current Tabellle ist immer mehr gewachsen (>200000 Einträge und kein Index) , bis die Web Oberfläche von FHEM gar nicht mehr reagiert hat, da die Ausführung von DbLog pro Eintrag in die Datenbank mehrere Sekunden gedauert hat. Nach dem Löschen der history und der current Daten, war alles wieder OK. Wie sich herausgestellt hat, war das löschen der History Daten unnötig, sondern nur die current Tabelle mit ihrer Größe ein Problem.

Nachdem ich feststellen musste, dass der current Table nach dem Löschen wieder anfing zu wachsen, habe ich mir die 93_DbLog.pm angesehen, was bei mir aber zu dem Falschen Schluss geführt hat, == 0 wäre nicht korrekt. -> Posting entsprechend editiert.

Danach bin ich darauf gestoßen, das die Tabellen für meine Konfiguration nicht ausreichend groß definiert sind und so zu Doppelten Zeilen in der current Tabelle führen können.

Daher habe ich die Tabellen current und history folgendermaßen angepasst:
MariaDB [fhem]> desc current;
+-----------+--------------+------+-----+-------------------+-----------------------------+
| Field     | Type         | Null | Key | Default           | Extra                       |
+-----------+--------------+------+-----+-------------------+-----------------------------+
| TIMESTAMP | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| DEVICE    | varchar(64)  | YES  |     | NULL              |                             |
| TYPE      | varchar(32)  | YES  |     | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(64)  | YES  |     | NULL              |                             |
| VALUE     | varchar(64)  | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+
7 rows in set (0.00 sec)

MariaDB [fhem]> desc history;
+-----------+--------------+------+-----+-------------------+-----------------------------+
| Field     | Type         | Null | Key | Default           | Extra                       |
+-----------+--------------+------+-----+-------------------+-----------------------------+
| TIMESTAMP | timestamp    | NO   | MUL | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| DEVICE    | varchar(64)  | YES  | MUL | NULL              |                             |
| TYPE      | varchar(32)  | YES  | MUL | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(64)  | YES  |     | NULL              |                             |
| VALUE     | varchar(64)  | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+
7 rows in set (0.00 sec)

Rein nebenbei habe ich noch ein paar Indizes auf die history Tabelle gelegt. Das ist aber derzeit, mit ein bischen in den Sourcecode Schauen, ein Schuß ins Blaue, ohne sich mal die tatsächlichen Zugriffe angesehen zu haben. Allerdings hoffe ich, dass dadurch die erzeugung der SVGs aus den DbLogs Beschleunigt ist. Da meine History Daten von knapp 2 Millionen Zeilen wieder auf 50.000 runter sind, kann ich hier aber erst mit der Zeit feststellen, ob das passt.

So wie es aussieht hat sich mit diesen Änderungen mein Problem mit dem current Table verflogen.

Gruß

Mario
4. Edit. Sorry, etwas Confus editiert.

Tobias

Im Standard gehören indexes zur Datenbank.  Warum waren die bei dir nicht angelegt???  Meine DB ist 10gb groß und ein normaler tagesplot wird in 2 bis 4 sek angezeigt

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter