DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Du hast bestimmt hier gespickelt  :)
Ich muß noch den Start des Subprocesses in die DefFn vorziehen. Dann wäre das erfüllt was Rudi in dem Thread ausgeführt hatte. Das mache ich heute noch.
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

DS_Starter

Gerade eben habe ich das Modul im contrib upgedated.

Der SubProzess wird nun gleich beim Define inititialisiert.
Bei "set ... reopen" erfolgt ebenfalls ein Schließen und Neustart des SubProzesses. Dadurch ist dann aber der Vorteil des zeitigen
Start im Define zunichte gemacht, aber das ist dann nicht zu ändern.
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

das sieht doch schon gut aus :)

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

7717 fhem      20   0  336156 267256  18572 S  14,6   6,8   1:16.70 perl     
7718 fhem      20   0   69940  60116   6900 S   8,6   1,5   0:14.04 perl
Einfacher FHEM Anwender auf Intel®NUC

Beta-User

Auch hier bisher keine Auffälligkeiten (Laufzeit aber auch erst knapp über eine Stunde).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Frank_Huber

So, hab die Version jetzt auch mal auf Zwei Instanzen laufen. bis jetzt keine Auffälligkeiten.

erwin

So, ich hab jetzt mal eine DbLog def in der cfg nach "vorne" geschoben, bringt definitiv was für mem use!
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
30337 fhem      20   0   44144  31368   1620 S   8.9  3.3   0:20.71 perl # dblog NR= 20
30343 fhem      20   0   83064  54696   1584 S   8.9  5.8   0:19.74 perl # dblog NR= 92
30330 fhem      20   0  118080  90284  12268 S   1.7  9.5   3:08.15 perl # main

Ein Versuch, $hash->{NR} automatisiert auf einen freien wert < 20 zu setzen, ist allerdings schiefgegangen....
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,...

Beta-User

#21
Zitat von: erwin am 01 Dezember 2022, 11:24:55
Ein Versuch, $hash->{NR} automatisiert auf einen freien wert < 20 zu setzen, ist allerdings schiefgegangen....
l.g. erwin
Da $devcount bei jedem define erhöht wird, funktioniert das "ganzzahltig" vermutlich nie. Ein workaround könnte sein, das für alle DbLog-Instanzen auf 1.{random} zu setzen, wenn deren automatisch vergebene NR größer ist wie (sagen wir) 10 - count TYPE=DbLog. Ist aber ziemlich "dreckig"...

EDIT: Zu "dreckig". Beim Speichern wird eine ganzzahlige ID erwartet...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DS_Starter

Unter dem Gesichtspunkt des Speicher sparens ist meine jetzige Implementierung dass ein "reopen" den Subprozess beendet und dann neu startet sehr kontraproduktiv.
Dann macht man sich den Vorteil, den man sich über die Reihenfolge beim Start verschafft hat, wieder kaputt.

Ich werde es anders machen und nur die DB-Verbindung innerhalb des SP abbauen bzw. wieder aufbauen (passiert aktuell ohnehin im asynchronen Betrieb). Aber da bin ich noch dran.
Sollte der SP mal sterben wird er automatisch neu erstellt, was dann aber zwangsläufig ohne den "Speichervorteil" passiert.
Ist aber wegen der Betriebssicherheit nötig.

Wegen der Sortierung  $hash->{NR} könnten wir uns ja eine sichere! programmtechnische Routine erdenken. Mal schauen.

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

Beta-User

#23
Zitat von: DS_Starter am 01 Dezember 2022, 12:40:10
Wegen der Sortierung  $hash->{NR} könnten wir uns ja eine sichere! programmtechnische Routine erdenken. Mal schauen.
Na ja. Das ist ein Internal. Man bräuchte ja "nur" eine Schleife von aktueller Position bis 2 rückwärts durchfahren und alle um eins erhöhen. Am Ende dann die DbLog-Instanz neu unter 2 einsortieren, done... Vielleicht noch bedingt dadurch, dass die aktuelle Position nicht sowieso schon klein ist (was auch immer das heißen mag). Sonst kommt es ggf. zu einer Dauer-Umsortierung, v.a., wenn das dann jemand nachmacht ;) .
Wirkt dann halt erst nach dem nächsten "save" (+restart).

EDIT: Es wäre besser, man könnte eine Art "high prio"-Flag setzen, anhand dem dann fhem.pl diese Devices dann automatisch beim save nach vorne sortiert, also erstes Sortierkriterium die mit flag (NR nur Hilfskriterium), danach der Rest wie sich das aus der NR ergibt. Würde halt Änderungen dieser einen Schleife beim wegspeichern bedingen, aber das wäre es dann schon gewesen und man wäre m.E. die Konflikte los...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

erwin

ZitatWegen der Sortierung  $hash->{NR} könnten wir uns ja eine sichere! programmtechnische Routine erdenken. Mal schauen.
Naja, das habe ich versucht:
- eine NR herausfinden, die 1) nicht belegt ist UND 2) < 20 ist.
- diese NR dann $hash->{NR} = .. setzten.

Das hat grundsätzlich funktioniert, INTERNAL NR war dann "richtig" gesetzt.
Allerdings: Nach einem save-shutdown-restart war das DbLog device dann nicht defined!!!

Interessant ist auch, dass ein nach vorne schieben in der cfg ein NR von 20 ergibt, obwohl zw. 1 und 19 noch etliche NICHT belegt sind...
Meine used NR's =< 20:

used NR: 5 WEB
used NR: 7 WEBphone
used NR: 9 WEBtablet
used NR: 14 autocreate
used NR: 16 eventTypes
used NR: 1 global
used NR: 19 initialUsbCheck
used NR: 20 myDbLog
used NR: 3 telnetPort
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,...

Beta-User

#25
Witzig.

Auf dem Testsystem liefert
list NR~.|1. NR
in der Tat Lücken.

Lasse ich das auf mein Hauptstem los, sind lückenlos alle Nummern belegt. Unterschied: Das läuft auf configDB.

Unter den nicht genutzten Nummern scheint sich fhem.pl die Leerzeilen (und Kommentare etc.) zu merken.
(EDIT: ja, "$h = $comments{$i};" nach einer entsprechenden Abfrage.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Die Luecken koennen auch wegen temporaeren at, FHEMWEB/MQTT Verbindungen, usw. entstehen.

DS_Starter

#27
Guten Abend zusammen,

soeben habe ich ein Update des Moduls in mein contrib geladen.

Die gesamte Steuerung bezüglich des SubProzess ist überarbeitet/ausgebaut. Das betrifft vor allem das Connect-Management zur DB, Management bei User/Passwort Änderungen bzw. Änderungen von Attributen die sich auf Connect-Paramter beziehen.

Weiterhin werden Änderungen durch das Online-Einlesen der Konfigdatei mit rereadcfg bzw. das Connect Management mit reopen im SubProzess gesteuert.
Der SubProzess selbst wird nicht mehr beendet (außer wenn der Prozess durch einen Fehler stirbt) um den Speichervorteil beim Start nicht zu verlieren.

Man kann aber mit dem neuen Setter "stopSubProcess" den SubProzess manuell beenden wenn man es braucht.

Das Attr "traceHandles" habe ich entfernt. Es war nur für mich für den Support vorhanden und nicht für den User bestimmt.
In der neuen Architektur hat es nun keinen Mehrwert mehr.

Die Ausgaben in state geben nun auch mehr Information an den User über den aktuellen Zustand des Devices in Verbindung mit SubProcess.

Es sind recht umfangreiche Weiterentwicklungen in der Logik und dem Code. Ich habe alles soweit getestet. Dennoch kann es natürlich das eine oder andere Problemchen geben.
Also mutig updaten und vor allem danach restarten.  :)

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

enno

93_DbLog.pm:v5.0.0-s26750/2022-12-02 keine Fehler im Log und alles Andere wie immer ohne erkennbare Unterschiede ausser, das der Subprocess kleiner ist als bei der Version von gestern.
121358 fhem      20   0  343028 272084  18512 S  10,6   7,0   2:15.57 perl     
121359 fhem      20   0   70136  48032   6952 R   9,0   1,2   0:59.35 perl   
Einfacher FHEM Anwender auf Intel®NUC

DS_Starter

#29
Das ist schonmal sehr gut.  :)

Du kannst auch gerne mal verbose erhöhen und dir bei restart / reopen diverse Meldungen im Log anschauen die sich auf den
SubProzess beziehen.

Zitat
... ausser, das der Subprocess kleiner ist als bei der Version von gestern....
Die Umnumerierung die wir oben andiskutiert haben, ist noch nicht berücksichtigt.
Aber der SubProcess wird gleich beim Define gestartet. Wenn du DbLog "manuell" in der fhem.cfg weit vorn einsortiert hast, spielt sich die RAM-Ersparnis wie beabsichtigt aus.
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