DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Zitat
Any ideas?
Ja, ist nur eine Warnung und ist schon im Fokus ... siehe Beitrag drüber ...

Ansonsten keine besonderen Voraussetzungen, Version ist funktionskompatibel zur offiziellen Version.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Die $memcount  Warnung sollte nun beseitigt sein.
Update im contrib.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

erwin

re: patch/Zeilennummern...
der patch besteht aus einer Zeile, in DbLog_Log:
  if(AttrVal ($name, 'verbose', 3) == 4) {
      if($log4rel) {
          Log3 ($name, 4, "DbLog $name - ################################################################");
          Log3 ($name, 4, "DbLog $name - ###              start of new Logcycle                       ###");
          Log3 ($name, 4, "DbLog $name - ################################################################");
          Log3 ($name, 4, "DbLog $name - number of events received: $max of device: $dev_name");
      }
  }

  my ($event,$reading,$value,$unit,$memcount);
  $memcount = 0;  #<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  my $err;
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,...

erwin

Vorschlag zu cacheUsage:
dass passt m.M. auch besser zum wording in der cmd-ref.
gestestet allerdings nur mit cacheEvents 2!
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,...

SusisStrolch

Zitat von: erwin am 05 Dezember 2022, 12:14:34
re: patch/Zeilennummern...
der patch besteht aus einer Zeile, in DbLog_Log:

Danke. Dann kann ich mal mein UTF-8 Problemchen testen...
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

DS_Starter

Danke erwin,

fast getroffen denke ich  ;)
Habe es etwas verändert übernommen.
Gerne wieder aus contrib laden und gegenchecken.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

erwin

Hallo Heiko,

Ja, das passt!
...auch wenn das readingsupdate ohne EVENT mir nicht ganz verständlich ist...
Aber aus Kompatibilitätsgründen macht das Sinn.
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

Zitat
...auch wenn das readingsupdate ohne EVENT mir nicht ganz verständlich ist...

Naja, lt. ComRef und wie es von mir auch gedacht war liegt der Schwerpunkt  auf der Erzeugung von entsprechenden Events dieses Readings. Ursprünglich war die Verwendung den Füllgrad des Caches durch den User loggen/überwachen zu können.
Upgedated werden sollte es unabhängig von der Eventerstellung.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

enno

Folgende Warnung habe ich im Log: 2022.12.05 21:41:14.371 1: PERL WARNING: Use of uninitialized value $v2[0] in regexp compilation at ./FHEM/93_DbLog.pm line 1516.

93_DbLog.pm:v5.2.0-s26750/2022-12-05 Sonst alles unauffällig.
Einfacher FHEM Anwender auf Intel®NUC

DS_Starter

Hallo enno,

ich denke das kommt von einem DbLogInclude Attr bei dem das Reading fehlt/nicht mitkommt.
Das ist eine Stelle die im offiziellen Modul auch so definiert ist.
Ich weiß nicht wie oft die Warnung bei dir kommt, man bekommt es mit einem verbose 5 raus.

verbose 5 schmeißt aber viele Daten. Wenn du keine Idee hast, mache ich für dich eine Version um herauszubekommen
was genau bei dir diese Warnung erzeugt.

ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

enno

Ich glaube das lohnt nicht. Ich habe die Meldung das erste Mal gesehen. Wenn das öfter passiert, drehe ich am Verbose. Ich bebachte weiter.

Edit: Ich habe in der SQL-Datenbank um genaue die Uhrzeit zwei Einträge meiner Heizung. Der Fehler kam von meiner Heizung "km200". Das Modul hatte ich heute morgen nach langen Zögern doch aktualisiert. Nun habe ich plötzlich einen ganzen Sack mehr Readings dort. Beim Hinzufügen zum Attr DbLogInclude hat sich das System wohl kurz "verschluckt".
Einfacher FHEM Anwender auf Intel®NUC

DS_Starter

Möglicherweise hilft dir auch das globale stacktrace einzuschalten.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

SusisStrolch

SQL-Error Handling
Habe extra mal 'nen fehlerhaften Event via "importCache" eingespielt (Fragment im Anhang) und bewusst auf DbLogValueFN verzichtet.
Sobald MariaDB einen Fehler meldet wird der zu Grunde liegende MemCache verworfen und nicht in ein Cache-File gesichert.
Unangenehm wenn man aus Performance-Gründen auf Einzeltransaktionen verzichten muß/will.
2022.12.05 15:34:37.310 4: DbLog logdb - 40 of 40 events inserted into table history
2022.12.05 15:34:37.998 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 33 generated 1 errors at ./FHEM/93_DbLog.pm line 2428.

2022.12.05 15:34:38.319 4: DbLog logdb - commit inserted data table history
2022.12.05 15:34:38.323 4: DbLog logdb - begin transaction
2022.12.05 15:34:38.881 4: DbLog logdb - insert history rolled back
2022.12.05 15:34:38.924 5: DbLog logdb - DbLog_Push Returncode: DBD::mysql::st execute_array failed: executing 33 generated 1 errors at ./FHEM/93_DbLog.pm line 2428.



Der Vollständigkeit halber hier das DbLog Device:
defmod logdb DbLog ./contrib/dblog/MariaDB10.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogSelectionMode Exclude/Include
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb bulkInsert 0
attr logdb cacheEvents 2
attr logdb cacheOverflowThreshold 750
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 128
attr logdb disable 0
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 86400
attr logdb verbose 5
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

DS_Starter

Moin,

im asynch Mode und mit Transaktion (default) wird der übergebene Datenstack wieder an den Cache zurück gegeben.
Das sollte klappen.

Ich habe gerade eben die nächste V ins contrib geladen. Mit verbose 5 sieht man die zurück gegebenen Daten im Log:

  Log3 ($name, 5, "DbLog $name - rowlback to Cache: $key -> ".$rowlback->{$key});

Weiterhin habe ich noch den CPU-Verbrauch der/des SubProcesses deutlich reduzieren können.
Probiers mal aus.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

SusisStrolch

Hmm, hat nicht so geklappt wie ich das erwartet habe.
Vorgehensweise:
Cache-File (1000 Zeilen) mit dem UTF-8 Fehler importiert.
Commit wurde abgebrochen. Ich hätte jetzt erwartet das die Cachegröße > 1000 ist und die Daten weiterhin im Cache stehen. Dies ist jedoch nicht der Fall.
defmod logdb DbLog ./contrib/dblog/MariaDB10.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogSelectionMode Exclude/Include
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb bulkInsert 0
attr logdb cacheEvents 2
attr logdb cacheOverflowThreshold 750
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 128
attr logdb disable 0
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 86400
attr logdb verbose 5

setstate logdb connected
setstate logdb 2022-12-06 10:36:44 CacheOverflowLastNum 0
setstate logdb 2022-12-03 15:42:58 CacheOverflowLastState normal
setstate logdb 2022-12-06 10:36:44 CacheUsage 19
setstate logdb 2022-12-06 10:36:44 NextSync 2022-12-06 10:37:14 or when CacheUsage 500 is reached
setstate logdb 2022-12-06 10:36:45 background_processing_time 0.2823
setstate logdb 2022-12-06 10:28:14 lastCachefile ./log/cache_logdb_2022-12-02-n1000 - Error - Resource temporarily unavailable
setstate logdb 2022-12-06 10:36:53 notify_processing_time 0.0048
setstate logdb 2022-12-06 10:36:45 sql_processing_time 0.2688
setstate logdb 2022-12-06 10:36:45 state connected



Im Filesystem ist auch keine neue Datei aufgetaucht, obwohl cacheOverflowThreshold auf 750 gesetzt ist.
Ich habe den entsprechenden Logfile-Auszug angehängt...
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch