93_DBLog verzögert Ausführen von FHEM für mehrerer Sekunden

[pantau]

Bei mir verzögert das aktuelle 93_DBlog.pm (aus dem SVN) die Abarbeitung von notifys für ca. 10 Sekunden.

Server: Intel Atom 1.6GHz, 2GB RAM

Datenbank: mysql (aktuell aus Ubuntu 12.04)

define logdb2 DbLog /home/FHZ/fhem/db.conf.mysql EM_Total:.*|EM_Solar:.*|EM_WZ:.*|EM_WaKe:.*|emaz:.*|emdc:.*|emgz:.*

Immer wenn nun Nachrichten von dem EM-Sensoren kommen, ist teilweise die Abarbeitung von FHEM blockiert.

Also Nachricht eines EM-Sensors kommt rein (sehe ich am FileLog), ich drücke die Taste am FS20 Sender, dann wird der notify
define n25 notify Bad_2:toggle set RollBad on
ca. 10 sec später ausgeführt (und auch erst dann im Filelog eingetragen). Er wird also nicht verschluckt, sondern verzögert.
Ohne gerade empfangene Nachrichten eines EM-Sensors wird der notify sofort ausgeführt, ebenso wenn ich das dblog deaktiviere.
Ich vermute das das DB Schreiben so lange dauert. Ich mache regelmäßig SVN Updates und hab das Problem erst seit relativ kurzer Zeit beobachtet.

[Johannes]

Besorg dir mal eine ältere Revision aus dem svn und schau ob damit wieder geht. Es wurden vor kurzem die inserts zusammengefasst statt sie einzeln abzuarbeiten. Das sollte eigentlich Vorteile bringen, könnte aber mit deinem Problem zusammenhängen..

[ThorstenH]

Hi,

wäre es nicht möglich, die DB Logeinträge asynchron in einem extra Thread zu verarbeiten? Dann würde fhem (der main thread) nicht blockieren.

Grüße
Thorsten

[Tobias]

ich behaupte mal, das es nicht am Modul liegt. Ich habs zwar eingecheckt, aber lange getestet.
Bei mir läuft FHEM und die Datenbank auf einem NAS-Storage, 1Ghz, mit ca 40 Devices, empfangen über alle möglichen Devices (RFXTRX, CUL, 1wire).
Die history Tabelle ist mittlerweile 5Mio Datensätze groß. Ich stelle keine Verzögerung fest!
Das muss bei dir woanders liegen. Und wenn an der DB, hast du mal manuell über die SQL-Konsole Datensätze eingetragen und die Zeit gemessen?

[pantau]

Ich gebe zu bezüglich Datenbanken bin ich blutiger Anfänger.
Meine Beobachtung ist bisher ganz makroskopisch: dblog Aufruf weg => Probleme weg.

Bevor ich da weiter suche, mal ein Verdacht:
Meine mysql fhem-Datenbank habe ich vor laaanger Zeit aufgesetzt.
Nun sehe ich im SVN das sich auch am Datenbankformat was geändert hat: "extended the event column for mysql from 64 to 512 characters"
Ich habe an meinem mysql nichts geändert, benutze nun aber das neueste DBLog Modul.
Können die Probleme damit zusammenhängen? Inkompatible Änderung?

[Tobias]

das denke ich wird nicht das schwerwiegende Problem sein. Aber an der Indexierung hat sich etwas geändert.
Passe bitte mal dein Datenmodell der Referenz in contrib/dblog/ an

[pantau]

Ich habe jetzt mal einen Test mit SQLITE gemacht.
Da sieht alles ganz gut aus, allerdings habe ich auch eine neue Datenbank angelegt, somit sind da noch kaum Datensätze drin.
Ich beobachte das weiter...
Kann ich meine mysql Datenbank so an die Referenz anpassen, daß keine Daten verloren gehen und wenn ja wie?
Wie gesagt blutiger Datenbankanfänger ...

[Tobias]

Geh mal bitte wieder auf deine alte DB zurück und stelle im DbLog das Attr "DbLogType" auf current und schaue ob immer noch die Verzögerungen auftreten. Falls ja, versuche mal die Einstellung "history" und berichte.
Falls beides nichts bringt, stell mal bitte auf "current" und mach in der DB ein "TRUNCATE TABLE current". Kann man auch über phpmyadmin machen

Auf jeden Fall musst du in der history Tabelle alle Indexe löschen und den im contrib/dblog angegebenen Index anlegen.