93_DbLog - Umstellung Log-Funktion auf non-blocking

[Loredo]

Da es deine Anforderung ist, würde ich Dich bitten, einen entsprechenden Patch für CallFn() in FHEM Development einzureichen.  Wenn das OK für dich ist.

Guckst du hier.
Mal schauen, wie/ob sich Rudi entscheidet das allgemein aufzunehmen. Derzeit sieht es eher so aus, als wenn wir hier zur moduleigenen Lösung zurückkehren sollen/müssen (ggf. mit eigener Funktion).

[DS_Starter]

Hi Loredo,

Ich werde in v2.9 noch die Commandref ergänzen und werde dabei wohl auch die beiden neuen Funktionen FlushCache und syncCache wahrscheinlich etwas umbenennen. Um die Abgrenzung beider Funktionen besser in der Begrifflichkeit zu manifestieren wird aus FlushCache dann resetcache und aus syncCache dann FlushCache so wie Joe es wohl ursprünglich verstanden hatte.

Bei der Gelegenheit werde ich die Entscheidung bzgl. Splitfn auch mit berücksichtigen wenn es eine gibt. Mal schauen.

VG
Heiko

[Ellert]

Gibt es eine optimale Datenmenge, wann der Cache geleert werden sollte?
Könnte der Cache bei dieser Menge nicht automatisch geschrieben werden, statt ein Intervall zu nutzen?

Kann ich davon ausgehen, dass der Cache beim shutdown geleert wird?

[Rewe2000]

Hallo,

auch bei mir sind mit der Version 2.9 die "MySQL server has gone away" Fehler verschwunden.
Test erfolgte mit "asyncMode" 0 und 1.

Danke für eure Mühe
Reinhard

[DS_Starter]

Hallo Reinhard,

danke auch für deine positive Rückmeldung !

VG
Heiko

[DS_Starter]

Hallo Ellert,

ich beginne deine Fragen mal von hinten zu beantworten ...

Kann ich davon ausgehen, dass der Cache beim shutdown geleert wird?

Ja, kannst du. Die entsprechende Schreibfunktion wird beim Shutdown aufgerufen.
Allerdings würde ich das immer schon vorhandene Attribut "shutdownWait" setzen. Ich habe es bei mir
auf 2s gesetzt und gute Erfahrungen damit gemacht. Die SQL-Zeit im asynchronen Modus liegt bei mir so
zwischen ca. 0,03 - 0,09s (kannst du mit Attr "showproctime" anzeigen lassen).
Du kannst ja mal schauen wie es bei dir damit aussieht.

Könnte der Cache bei dieser Menge nicht automatisch geschrieben werden, statt ein Intervall zu nutzen?

Das hatte ich vor mit als Nächstes zu implementieren. Wahrscheinlich werde ich es so machen, dass der Schreibvorgang in
die DB beim Erreichen einer der gesetzten Grenzwerte, also entweder die gwünschte Anzahl der Einträge im Cache oder das eingestellte
"syncInterval" gestartet wird.
Das hätte auch den positiven Nebeneffekt, dass der Cache auf jeden Fall in die DB weggeschrieben wird falls der Timer aus welchen Gründen
auch immer, mal versagen sollte.

Gibt es eine optimale Datenmenge, wann der Cache geleert werden sollte?

Darüber habe ich mir eigentlich noch keine Gedanken gemacht. Das hängt IMHO einerseits von den Wünschen des Users ab,
wie schnell er seine Daten aktuell in der DB haben möchte und andererseits von den Systemressourcen.
Ich habe mich bei der Erstellung der asynchronen Modes davon leiten lassen, eine weitgehende Entflechtung des Schreibvorgangs
der Daten in die DB von den anderen Abläufen im FHEM zu erreichen um die allgemeine Performance zu steigern.
Man müßte vllt. mal einen Test machen wie schnell eine sehr große aufgelaufene Datenmenge (vllt. nach 1 Stunde)in die DB weggeschrieben
wird. Habe ich noch nicht probiert.
Aber angenommen hatte ich, dass die Schreibyklen im Normalfall so bei 60s +/- liegen würden.
In beiden Modi (synchron bzw. asynchron) werden die vorhandenen Daten als Block in die DB geschrieben.

Viele Grüße
Heiko

[JoeALLb]

[...] Abgrenzung beider Funktionen besser in der Begrifflichkeit zu manifestieren wird aus FlushCache dann resetcache und aus syncCache dann FlushCache so wie Joe es wohl

in FHEM hat es sich eingebürgert, mit kleinen Buchstaben zu beginnen und zwischendrinnen einen Großbuchstaben einzubinden.
Zusätzlich habe ich auch nochmal über den Namen nachgedacht und würde folgende Vorschlagen, da diese eindeutig sind:
# commitCache
# purgeCache

(Ich kann aber mit den anderen Namen selbverständlich auch sehr gut leben!)

[DS_Starter]

Hi Joe,

ja, das mache ich auch. Von meinem Mobilteil geschriebene Texte werden oft durch die Texterkennung/Autokorrektur verfälscht.
Da kommen manchmal merkwürdige Dinge an ...

VG

[JoeALLb]

Aber angenommen hatte ich, dass die Schreibyklen im Normalfall so bei 60s +/- liegen würden.
In beiden Modi (synchron bzw. asynchron) werden die vorhandenen Daten als Block in die DB geschrieben.

Ich habe mal mit 30 Minuten getestet und dabei 3600 Datensätze im Cache produziert.
Diese wurden in 1,2s in die DB geschrieben, auf einem eher langsamen Watt-optimierten Server (jedoch mit ssd).
Wenn ich also mit 300ms Speicherzeit alle 10 Minuten rechne, habe ich viel gewonnen und das System reagiert deutlich schneller.

Bei zu vielen Datensätzen hätte ich tatsächlich mal die Sorge, sie zu verlieren, wenn irgendein Modul abschmiert oder zu viel Speicher
nutzen möchte, aber 10 Minuten ist für mich ein durchaus denkbarer Wert wür eine noch kleinere RPI-Installation, die die Daten auf eine SD-Karte schreibt.
Da diese SD-Karten nicht gerne viele Schreibvorgänge mögen, wurde hier bisher immer eher FileLog empfohlen. Ich habe mit DbLog jedoch sehr gute und zuverlässige Erfahrungen gemacht!

[PatrickR]

Hi!

# commitCache
# purgeCache

(Ich kann aber mit den anderen Namen selbverständlich auch sehr gut leben!)

Um ehrlich zu sein finde gerade flushCache in seiner bisherigen "Belegung" ausgesprochen unglücklich und irreführend. Autoflush in Perl vernichtet ja auch keine Daten. Insofern wäre ich auch mit purgeCache wesentlich glücklicher und ich glaube, damit erspart man sich auch viel Supportaufwand im Forum.

Patrick

[stromer-12]

Wenn ich mich da mal zwischen drängeln darf. Bei mir sieht das nicht so aus wie bei Dir

Code Auswählen Erweitern


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


Ne Idee was nun "besser" oder "schlechter" ist?

Bei mir sieht die Datenbank so aus:

Code Auswählen Erweitern

mysql> show COLUMNS  from 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(64)  | YES  |     | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(64)  | YES  | MUL | NULL              |                             |
| VALUE     | varchar(128) | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+
7 rows in set (0.00 sec)

[Markus Bloch]

Bei der Gelegenheit werde ich die Entscheidung bzgl. Splitfn auch mit berücksichtigen wenn es eine gibt. Mal schauen.

Rudi hat mit Revision 13053 & 13054 eine Abwandlung von CallFn() eingecheckt, welche genau die von Loredo gewünschte Vorgehensweise umsetzt.

Anstatt CallFn() müsstest du nun CallInstanceFn() verwenden. Die Syntax für Parameter und Rückgabewerte sind identisch.

Ich habe beide Funktionen im Wiki beschrieben:
https://wiki.fhem.de/wiki/DevelopmentModuleAPI#CallInstanceFn
https://wiki.fhem.de/wiki/DevelopmentModuleAPI#CallFn

Ich denke das ist ein guter Kompromis für alle.

[DS_Starter]

@Joe, Patrick ... nehme eure Anregung gerne auf

# commitCache  -> schreiben in DB + leeren Cache
# purgeCache -> löschen Cache

und sehe das so vor. Habe mich auch mit der Begriffsfindung schwer getan.

@Markus, danke für die Info. baue ich so ein.

Grüße
Heiko

[stromer-12]

Ich habe mal mit 30 Minuten getestet und dabei 3600 Datensätze im Cache produziert.
Diese wurden in 1,2s in die DB geschrieben, auf einem eher langsamen Watt-optimierten Server (jedoch mit ssd).
Wenn ich also mit 300ms Speicherzeit alle 10 Minuten rechne, habe ich viel gewonnen und das System reagiert deutlich schneller.

Bei zu vielen Datensätzen hätte ich tatsächlich mal die Sorge, sie zu verlieren, wenn irgendein Modul abschmiert oder zu viel Speicher
nutzen möchte, aber 10 Minuten ist für mich ein durchaus denkbarer Wert wür eine noch kleinere RPI-Installation, die die Daten auf eine SD-Karte schreibt.
Da diese SD-Karten nicht gerne viele Schreibvorgänge mögen, wurde hier bisher immer eher FileLog empfohlen. Ich habe mit DbLog jedoch sehr gute und zuverlässige Erfahrungen gemacht!

Ich habe mal auf meinen Cubie mit 30min und 1800 Datensätze ca 51Sekunden zum wegschreiben benötigt.
Ich habe aber vermutlich zugroßen Index-Overheat.

[JoeALLb]

Ich habe mal auf meinen Cubie mit 30min und 1800 Datensätze ca 51Sekunden zum wegschreiben benötigt.
Ich habe aber vermutlich zugroßen Index-Overheat.

Welche Festplatte?
Datenbank mit UTF8 oder mit normalem Zeichensatz angelegt?
MyISAM oder INNODB?
MySQL oder MariaDB?

Ich habe einiges getestet, um die Performance halbwegs ordentlich bei kleinem Ressourcenverbrauch hinzubekommen.
Der RPI 1 hatte einfach nicht viel Leistung