DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

[DS_Starter]

Hallo Bernd,

Bin mir aber ziemlich sicher, dass von der Umstellung die Events nicht da waren. Die SyncDB hat ja nichts zu tun, außer wenn sie zum 'Sync' getriggert wird, daher verwundert es mich.

Da hast du recht dass es jetzt mehr Events dieser Art gibt. Allerdings durchläuft ein Event immer dein DbLog Device (Notify-Sub). Ob das Device etwas zu tun hat, entscheidet sich ja erst während der Verarbeitung bzw. Auswertung der Parameter. Deswegen gibt es diese NotifyTime Events.

OK, DbRep erstellt dann auch Subprozesse von DbLog?

DbRep arbeitet mit temporären BlockingCalls. D.h. es werden parallele Prozesse erstellt die wieder beendet werden wenn die Aufgabe abgearbeitet wurde.

Die meisten DbReps laufen bei mir nicht parallel und doch zähle ich nach längerer Betriebszeit von Fhem immer mehr Subprozesse von DbLog.

Das müsstest du genauer erläutern wie du zu der Annahme kommst diese Subprozesse kämen von DbLog.

Von DbRep hatte ich auch immer wieder timeouts im Log. Kann es sein, dass bei einem timeouts der Subprozesse nicht beendet wird?

Nein. Wenn ein BlockingCall gestartet wird, bekommt die zentrale FHEM-Schleife den Timeout Parameter übergeben. Der gestartete Prozess wird dann von FHEM (zentral) abgebrochen. Erst dann erscheint der Logeintrag, nicht andersherum.

LG,
Heiko

[frober]

Das müsstest du genauer erläutern wie du zu der Annahme kommst diese Subprozesse kämen von DbLog.

Danke Heiko für die Erläuterungen.

Wie schon geschrieben, alles mysql Prozesse. Da nur DbLog darauf zugreift, wüsste ich nicht woher diese kommen sollten.

Code Auswählen Erweitern

737 mysql      20  0  600M  153M  7036 S  0.0 16.6  8:33.14 /usr/sbin/mysqld
  802 mysql      20  0  600M  153M  7036 S  0.0 16.6  0:53.39 /usr/sbin/mysqld
 7094 mysql      20  0  600M  153M  7036 S  0.0 16.6  0:08.10 /usr/sbin/mysqld
  792 mysql      20  0  600M  153M  7036 S  0.0 16.6  0:20.15 /usr/sbin/mysqld



[DS_Starter]

Das sind aber MySQL Prozesse (kein Perl). Die entstehen z.B. auch über die Ausführung von SVG-Devices. Du könntest mit einem SQL Editor anschauen was die machen.
Alternativ geht das auch mit einem DbRep Device:

  get ... procinfo

[frober]

Das sind aber MySQL Prozesse (kein Perl). Die entstehen z.B. auch über die Ausführung von SVG-Devices. Du könntest mit einem SQL Editor anschauen was die machen.
Alternativ geht das auch mit einem DbRep Device:

  get ... procinfo

OK, danke. Dann habe ich das falsch interpretiert.

[DS_Starter]

Wenn natürlich immer mehr mysql Prozesse entstehen die nicht wieder abgebaut werden wäre das tatsächlich ein Fehlerzustand. Frage ist dann natürlich wie diese entstehen und müsste untersucht werden.

[ch.eick]

Da wäre auch noch Grafana zu erwähnen, falls das verwendet wird.
Bei meinem Dashboard hatte ich da, aufgrund der vielen Anzeigewerte, sehr viel MySQL Abfragen, da Grafana jeden Wert separat abgefragt hat.
Erst als ich das in ein SELECT, also auch nur eine Session, zusammen gefasst hatte war endlich ruhe und Grafana lief dann auch flüssiger.

VG   Christian

[frober]

Danke für die Info.
Grafenau benutze ich noch (?) nicht.

Ich hatte noch keine Zeit danach zu schauen. Da die Prozesse recht jung sind, wollte ich erst noch prüfen, ob diese auch da sind, wenn ich Fhem nicht erst benutzt habe (Plots etc. angeschaut).