FHEM-Auslastung bei 100%

Begonnen von Guzzi-Charlie, 17 November 2019, 09:25:45

Vorheriges Thema - Nächstes Thema

Guzzi-Charlie

@rudolfkoenig

Ich habe die Zeitintervalle bei den MQTT-Quellen erhöht (erstmal nur auf 60s) und habe am MQTT2-Server das raw-attr entfernt.

Das hat jetzt schon einen großen Hub gebracht. Die CPU-Last liegt jetzt wieder deutlich unter 100%, meistens um die 75%, schwankt natürlich auch (nach unten bis auf ca. 30% und nach oben auf 85%, ganz selten auch kurz mal auf 100%).

Jetzt werde ich versuchen das Ganze weiter zu optimieren (zumindest im Rahmen meiner Möglichkeiten).

Wichtig und Gut für mich war, daß ich Hinweise bekommen habe wo ich suchen kann.

Nochmals vielen Dank dafür.

Grüße
- RaspPI 4+: (Cuno V2 -2x KS300, JeeLink -13x EC3000)
- Stromzähler (B+G E-Tech): 6x SDM120M, 9x XTM100A, 38x DRS110M
- LAN: IT LAN-Gateway mit 34x RMF-R1 (Rohrmotor24)
- WLAN: 85x Shelly, 12x Gosund SP111, 16x D1-Mini, 15x Sonoff Basic
- DECT: 6x DECT200, 8x DECT301, - HmIP: 3x FalmotC12, 16x WTH2

rudolfkoenig

@Guzzi-Charlie: ich habe versucht das Parsen bei vielen MQTT Endgeraeten zu optimieren.
Da es komplexer ist, als die alte Variante, wuerde ich es nur dann einchecken, falls es hilft.
Koenntest du bitte die Auslastung der angehaengten Version mit der alten Version vergleichen?

Weiterhin haette ich gerne die Ausgabe von{ MQTT2_DEVICE_dumpInternal() }gesehen, diese Funktion gibt es nur in der angehaengten Variante.

Guzzi-Charlie

Hallo,

vielen Dank für die Mühe. Das werde ich gerne austesten und dann das Ergebnis mitteilen. Heute Abend komme ich aber leider nicht mehr dazu. Fahre Morgen Früh für zwei Tage an den Ammersee. Bin Mittwoch Abend wieder zurück, dann werde ich es testen.

Grüße
- RaspPI 4+: (Cuno V2 -2x KS300, JeeLink -13x EC3000)
- Stromzähler (B+G E-Tech): 6x SDM120M, 9x XTM100A, 38x DRS110M
- LAN: IT LAN-Gateway mit 34x RMF-R1 (Rohrmotor24)
- WLAN: 85x Shelly, 12x Gosund SP111, 16x D1-Mini, 15x Sonoff Basic
- DECT: 6x DECT200, 8x DECT301, - HmIP: 3x FalmotC12, 16x WTH2

rudolfkoenig


Guzzi-Charlie

Hallo Rudolf,

was soll ich sagen? Ich bin einfach noch nicht dazu gekommen. Erst Ammersee, dann 2-Tage auf Weinauslieferungstour mit meinem Kumpel (hat ein Weingut, aber gerade eine operierte Hand), dann noch die letzten schönen Tage genutzt um das Holz einer Dachgaube zu streichen, Heute Morgen Heizung ausgefallen ==> Fehlersuche (Zündtrafo defekt), neuen bestellt (Heizung solange AUS) und alle "freuen sich".

UND, da die Last nach den ersten Maßnahmen sich nun zwischen 60 und 80% bewegt und alles wieder soweit funktioniert war die PRIO etwas nach Hinten gerutscht.

Aber ich werde die nächsten Tage mich wieder dem Thema widmen (nachdem die Heizung wieder läuft). Ich will ja auch noch weitere Dinge in FHEM einbinden, auch weitere MQTT-"Sender".

Ich melde mich auf jeden Fall wieder.
- RaspPI 4+: (Cuno V2 -2x KS300, JeeLink -13x EC3000)
- Stromzähler (B+G E-Tech): 6x SDM120M, 9x XTM100A, 38x DRS110M
- LAN: IT LAN-Gateway mit 34x RMF-R1 (Rohrmotor24)
- WLAN: 85x Shelly, 12x Gosund SP111, 16x D1-Mini, 15x Sonoff Basic
- DECT: 6x DECT200, 8x DECT301, - HmIP: 3x FalmotC12, 16x WTH2

Romoker

Ich klinke mich hier mal ein. Ich habe zwar nur fünf MQTT-Devices, habe aber auch einen signifikanten CPU-Anstieg festgestellt, immer wenn die weihnachtlichen Lichterketten mit den SmartPlugs eingeschaltet wurden. Grund ist die Leistungsmessung der Plugs. Das führt zu einer hohen Frequenz an MQTT-Nachrichten und einem CPU-Lastanstieg von ca. 12% auf 30%. Ich war neugierig auf die Optimierung und habe die neue Version 10_MQTT2_DEVICE.pm getestet.
Zuerst habe ich keine Veränderung feststellen können, bis ich gemerkt habe, dass über autocreate nochmal alle meine vorhandenen MQTT2-Devices neu angelegt wurden und somit doppelt vorhanden waren. Nach Ausschalten von autocreate und Löschen der neuen Devices hat sich mit der neuen Version der CPU-Verbrauch gegenüber der alten Version halbiert (siehe Anhang).
Hier der Dump meiner MQTT2-Devices:
bridge
cid
  DVES_26D6E7
  DVES_26DDCB
  DVES_26E77B
  DVES_D44D02
  shellyplug_s_79A565
re
re:DVES_26D6E7
  DVES_26D6E7:tele/SmartPlug05/SENSOR:.*
  DVES_26D6E7:tele/SmartPlug05/STATE:.*
re:DVES_26DDCB
  DVES_26DDCB:tele/SmartPlug02/SENSOR:.*
  DVES_26DDCB:tele/SmartPlug02/STATE:.*
re:DVES_26E77B
  DVES_26E77B:tele/SmartPlug04/SENSOR:.*
  DVES_26E77B:tele/SmartPlug04/STATE:.*
re:DVES_D44D02
  DVES_D44D02:tele/SmartPlug03/SENSOR:.*
  DVES_D44D02:tele/SmartPlug03/STATE:.*
re:shellyplug_s_79A565
  shellyplug_s_79A565:shellies/shellyplug-s-79A565/overtemperature:.*
  shellyplug_s_79A565:shellies/shellyplug-s-79A565/relay/0/power:.*
  shellyplug_s_79A565:shellies/shellyplug-s-79A565/relay/0:.*
  shellyplug_s_79A565:shellies/shellyplug-s-79A565/temperature:.*
  shellyplug_s_79A565:shellies/shellyplug-s-79A565/temperature_f:.*


Test erfolgreich!

Weihnachtliche Grüße
BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

rudolfkoenig

Danke fuers Feedback, ich habe die Version eingecheckt.

Achtung: Diese Optimierung greift nur, wenn MQTT2_DEVICE eine eindeutige ClientId hat. Bei MQTT2_SERVER ist das normalerweise der Fall, bei MQTT2_CLIENT muss das ueber ein Bridge-Device erfolgen.

Guzzi-Charlie

Hallo,

bin nun auch endlich dazu gekommen das Update einzuspielen (Heizung läuft wieder und die Frau ist auch wieder zufrieden).

Wie es scheint zeigt es auch bei mir Wirkung. Geschätzt liegt die mittlere Last jetzt ca. 15% niedriger. Vielen Dank für die Verbesserung (siehe Screenshot).

Ich werde aber trotzdem versuchen noch weiter zu optimieren.


Grüße und schöne Weihnachten
Bernd
- RaspPI 4+: (Cuno V2 -2x KS300, JeeLink -13x EC3000)
- Stromzähler (B+G E-Tech): 6x SDM120M, 9x XTM100A, 38x DRS110M
- LAN: IT LAN-Gateway mit 34x RMF-R1 (Rohrmotor24)
- WLAN: 85x Shelly, 12x Gosund SP111, 16x D1-Mini, 15x Sonoff Basic
- DECT: 6x DECT200, 8x DECT301, - HmIP: 3x FalmotC12, 16x WTH2