DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

Begonnen von DS_Starter, 29 November 2022, 12:54:25

Vorheriges Thema - Nächstes Thema

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

enno

Moin Heiko,

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
Einfacher FHEM Anwender auf Intel®NUC

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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
Einfacher FHEM Anwender auf Intel®NUC

helmut

Hallo Heiko,

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

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


Gruss Helmut
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

DS_Starter

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


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


Ein reload reicht da nicht.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

helmut

Hallo Heiko,

Du hast recht. Aber jetzt:

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

Gruss Helmut
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

Jamo

Habs auch am laufen, bisher unauffällig. Aus dem Log:
DbLog myDbLog - Subprocess "31088" initialized ... ready for non-blocking operation

Die Attribute, und die FVERSION
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
...
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

erwin

läuft!
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


   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!
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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

DS_Starter

#9
Moin erwin,

danke für die Info.


  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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Sany

Guten Morgen,

habe gerade die Version 5 auf einem meiner (Test)systeme eingebaut, das lief problemlos.
ZitatFVERSION   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
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

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 ...  8)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

DS_Starter

Zitatein set ... reopen sollte den child prozess ebenfalls terminieren und neu starten ...
Guter Hinweis, sehe ich mit vor.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

enno

ich bin noch dabei.  :) 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:
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
Einfacher FHEM Anwender auf Intel®NUC