DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

[DS_Starter]

Hallo zusammen,

in meinem contrib (siehe Fußtext) habe ich eine Testversion DbLog 5.0.0 zur Verfügung gestellt.

Für den asynchronen Betrieb habe ich nun anstelle des sich wiederholenden BlockingCall das SubProcess-Verfahren implementiert.
Das Verhalten ist wie bisher mit asyncMode = 1.

Wenn alles klappt wie ich es beabsichtige, werde ich auch das nicht-asynchrone Verfahren auf SubProcess umstellen und dadurch das Logging
generell non-blocking zur Verfügung stellen.

Das Ganze ist noch nicht fertig, läuft bei mir aber schon soweit reibungslos.

Ich würde mich freuen wenn sich ein paar Tester finden würden.
Denkt aber bitte daran, dass durchaus noch Fehler auftreten können und ihr solltet diesbezüglich eine gewisse Toleranz mitbringen. 

LG,
Heiko

[enno]

Moin Heiko,

Code: [Auswählen]

2022.11.29 13:13:52.252 2: DbLog MYSQL - Subprocess "1643166" initialized ... ready for non-blocking operation
ich beobachte. Start schon mal ohne Auffälligkeiten.

Gruss
  Enno

[DS_Starter]

Wow , du bist ja fix 

[enno]

Moin Heiko,

solche Test würde ich nicht bei allen Modulen hier wagen. Da gibt es einige reguläre Module, die ich vom Update ausgeschlossen habe und erst mal ein paar Tage im Forum beobachte bevor ich die aktuellen Versionen einspiele, weil sie immer wieder mit kleinen Tippfehlern oder nicht angekündigten Änderungen aufschlagen.

Deine Testversion läuft bei mir ohne irgendwelche Probleme. Ich kann als User keine Unterschiede zu der normalen Version erkennen. So hatte ich es erwartet Bin gespannt wie es weiter geht.

Gruss
  Enno

[helmut]

Hallo Heiko,

auch bei mir sieht es bis jetzt gut aus und ich werde weiter beobachten.

Code: [Auswählen]

list DbLog
[...]
   FVERSION   93_DbLog.pm:v1.1.1-s26750/2022-11-26
Gruss Helmut

[DS_Starter]

Danke auch dir Helmut.
Die Version wird richtig nach einem FHEM Restart angezeigt:

Code: [Auswählen]

FVERSION  93_DbLog.pm:v5.0.0-s26750/2022-11-26

Ein reload reicht da nicht.

[helmut]

Hallo Heiko,

Du hast recht. Aber jetzt:

Code: [Auswählen]

   FVERSION   93_DbLog.pm:v5.0.0-s26750/2022-11-26
Gruss Helmut

[Jamo]

Habs auch am laufen, bisher unauffällig. Aus dem Log:

Code: [Auswählen]

DbLog myDbLog - Subprocess "31088" initialized ... ready for non-blocking operation
Die Attribute, und die FVERSION

Code: [Auswählen]

attr myDbLog DbLogType Current/History
attr myDbLog asyncMode 1
attr myDbLog bulkInsert 1
attr myDbLog syncInterval 120
...
#   FVERSION   93_DbLog.pm:v5.0.0-s26750/2022-11-26
#   MODE       asynchronous
#   MODEL      SQLITE
#   NAME       myDbLog
...


[erwin]

läuft!

Code: [Auswählen]

2022.11.30 08:09:13.590 2: DbLog myDbLog - Subprocess "22837" initialized ... ready for non-blocking operation
2022.11.30 08:09:13.889 3: DbLog myDbLog - Creating Push-Handle to database mysql:database=fhem;host=192.168.5.245;port=3306 with user fhemuser
2022.11.30 08:09:13.913 3: DbLog myDbLog - Push-Handle to db mysql:database=fhem;host=192.168.5.245;port=3306 created
2022.11.30 08:09:13.914 3: DbLog myDbLog - UTF8 support enabled
2022.11.30 08:09:13.946 2: DbLog CL_DbLog - Subprocess "22839" initialized ... ready for non-blocking operation
2022.11.30 08:09:13.974 3: DbLog CL_DbLog - Creating Push-Handle to database mysql:database=fhem;host=192.168.5.13;port=3306 with user fhemuser
2022.11.30 08:09:13.983 3: DbLog CL_DbLog - Push-Handle to db mysql:database=fhem;host=192.168.5.13;port=3306 created
2022.11.30 08:09:13.984 3: DbLog CL_DbLog - UTF8 support enabled


Code: [Auswählen]

   FVERSION   93_DbLog.pm:v5.0.0-s26750/2022-11-26
   MODE       asynchronous
   MODEL      MYSQL
....
Attributes:
   DbLogSelectionMode Include
   DbLogType  History
   asyncMode  1
   bulkInsert 1
   cacheEvents 2
   colEvent   0
   excludeDevs myDbLog
   room       Global
   showproctime 1
   syncInterval 120
   timeout    86400
Was mir allerdings auffällt, ist das die geforkten Prozesse beinahe soviel CPU % brauchen - wie der main prozess.
...Ich habe 2 DbLog-defs auf diesem Test-system! - ist allerdings ein RPI-2!

Code: [Auswählen]

22837 fhem      20   0  117552  84908   7404 S   9.2  9.0   2:10.21 perl
22839 fhem      20   0  117536  81480   3940 S   9.2  8.6   2:09.57 perl
22726 fhem      20   0  121136  93420  12312 S   8.9  9.9   4:44.90 perl
Danke für die Weiterentwicklung dieses wesentlichen Moduls!
l.g. erwin
Danke

[DS_Starter]

Moin erwin,

danke für die Info.

Code: [Auswählen]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  713 fhem      20   0  430360 357900  22584 S   7,3  17,5   1:07.97 perl
  702 fhem      20   0  793016  83532  34832 S   2,3   4,1   0:04.31 homebridge
 1697 fhem      20   0  401684 309404   1328 S   2,3  15,2   0:02.32 perl
 1688 fhem      20   0  401368 309068   1328 S   2,0  15,1   0:02.56 perl
 1693 fhem      20   0  401652 309288   1328 R   2,0  15,1   0:02.32 perl
 1695 fhem      20   0  401652 309340   1328 S   1,7  15,2   0:02.35 perl
 1698 fhem      20   0  401836 309484   1328 R   1,7  15,2   0:02.32 perl
 1689 fhem      20   0  403044 313692   4332 S   1,3  15,4   0:02.39 perl
 1690 fhem      20   0  401520 309136   1328 S   1,3  15,1   0:02.20 perl
 1696 fhem      20   0  401652 309340   1328 S   1,3  15,2   0:02.31 perl

Habe gleich mal bei mir geschaut. Auf meinem Testsystem laufen 8 DbLog Instanzen.
Sie brauchen deutlich weniger CPU als der Hauptprozess. Ist allerdings ein Intel NUC mit VMWare + VM's.
Aber ich beobachte das mal.

LG

[Sany]

Guten Morgen,

habe gerade die Version 5 auf einem meiner (Test)systeme eingebaut, das lief problemlos.

   FVERSION   93_DbLog.pm:v5.0.0-s26750/2022-11-26
   MODE       asynchronous
   ...
   DbLogType  History
   asyncMode  1
   bulkInsert 1
   colEvent   0
...

es gibt hier aber nicht viele Devices, die Daten in die DB schreiben. Ich werde vermutlich keinen Unterschied in der Performance "spüren"

ein htop zeigt mir 4 zusätzliche instanzen von fhem, nur die Hautinstanz braucht ein paar %, die andern mehr oder weniger bei 0% (Raspi4).

Falls Du irgendwas getestet haben möchtest: einfach schreiben....

Gruß

Sany

[DS_Starter]

Rein von der Bedienung und der "User Experiance" her sollte sich kein Unterschied zur offiziellen Version ergeben.

Das forken durch BlockingCall fällt weg und dadurch sollte ich ein stabiler RAM-Verbauch abzeichnen. Es gibt natürlich noch mehr Module die BlockingCall verwenden (zB. DbRep).
Das muss man bisschen berücksichtigen bei den Beobachtungen.

Ansonsten soll die Version ganz normal werkeln.

Ich habe gerade ein Update des Moduls ins contrib geladen.
Beim Shutdown werden die SubProzesse in der entsprechenden Funktion beendet und das auch mit verbose 2 im Logfile protokolliert.

Ich arbeite weiter an der Code-Überarbeitung, achte aber sehr darauf dass sich keine Inkompatibilitäten einschleichen.
Aber dafür testen wir ja zusammen ... 

[erwin]

Ok, die neue version hab ich noch nicht,
aber einen Kommentar:
ein set ... reopen sollte den child prozess ebenfalls terminieren und neu starten, damit könnte man sich eine "dynamische" Übergabe von Parametern (cachelimit, syncinterval,...) evtl. ersparen.
l.g. erwin

[DS_Starter]

ein set ... reopen sollte den child prozess ebenfalls terminieren und neu starten ...

Guter Hinweis, sehe ich mit vor.

[enno]

ich bin noch dabei. 

Code: [Auswählen]

93_DbLog.pm:v5.0.0-s26750/2022-11-29 ich habe FHEM gestoppt und als keiner zugeschaut hat direkt in der fhem.cfg die Definition von DbLog hinter Global gespeichert. War bei mir vorher ca. im letzten Drittel. Top sagt aber zu Speicherverbrauch fast das Gleiche wie gestern:

Code: [Auswählen]

559 fhem      20   0  338128 269904  18992 R  14,3   6,9   1:46.89 perl                                       
575 fhem      20   0  306820 228564   7340 R   8,3   5,9   0:37.08 perl
Ich bin auf einem NUC mit Proxmox CT und aktuellen Debian (Bullseye) unterwegs.

Gruss
  Enno