fhem auf Raspi 4 100% cpu load

[Hackstall]

Hi mein fhem ist sehr langsam geworden.
Immer wieder alle 20 braucht mein fhem ca 100% für 10sec.

Ich habe schon viel gelesen aber alles hat nicht geholfen.

Ich betreiber fhem in einem DockerContainer und auch den MQTT Server in einem anderen Container.
Beides läuft auf einem RASPI4.

Irgendwie mache ich mir Sorgen für Erweiterungen.

Ich habe diese Verhalten seit ungefähr 6 Monaten und war anfänglich der Meinung dass es nach einem
Update kam.

Gibt es etwas dass ich überprüfen kann?
Wie geht man hier am besten vor?

Einen Umzug auf einen NUC würde dann doch etwas Arbeit bedürfen wobei ich natürlich zunächst herausfinden möchte woran es liegt?

Danke für Eure Hilfe

P.S.: Auch der Start dauert sehr lange. Am Memory liegt es nicht. Genug vorhanden und kein Swapping
P.P.S: Ich habe dann doch einige Fhem2Fhem Devices auf einem anderen Rechner der viele Devices aus meinem langsamen Raspi spiegelt. Ist das ev. ein Problem?

[rabehd]

Immer wieder alle 20 braucht mein fhem ca 100% für 10sec.

??

[tomcat.x]

Wenn Du schreibst, dass fhem 100% (CPU?) braucht, hast Du schon geschaut, dass es wirklich der fhem Prozess ist. Sonst hätte ich gesagt, dass man erst mal mit "top" schauen könnte, ob es fhem, der MQTT-Server oder was anderes ist.

Dann wäre natürlich die Frage von rabehd interessant: Alle 20 Sekunden (?) für 10 Sekunden? Dann läuft ja fast nichts mehr. Sieht man zu der Zeit im Log, was da aktiv ist/war? Ansonsten könnte es entweder ein bestimmtes Modul sein oder irgendwas löst zu einem Zeitpunkt viele Events aus, auf die vielleicht auch noch was anderes reagiert. So was hatte ich mir schon mit einer User-Function "gebaut" Da nutze ich gerne die DOIF-Tools (auch ohne DOIF). Da gibt es eine Funktion, Events statistisch auszuwerten. Da sieht man schön, ob da was außerordentlich viel auslöst. Geht natürlich auch ohne die DOIF-Tools, aber ich finde das praktisch und kann man ja hinterher wieder raus schmeißen.

Falls es von einem einzelnen Modul kommt und man nichts konkretes findet, könnte man die nur nacheinander deaktivieren und dann schauen. Ideal wäre natürlich, wenn man einen Verdacht hat ...

Viele Grüße
Thomas

[KölnSolar]

Ich werfe mal das freezemon-Modul zur Analyse in den Ring......

[Hackstall]

Danke für die Antworten und ja so ziemlich alle 10sec und ja est ist der Perl FHEM.pl Prozess gemäß htop.

Events im Event Monitor angezeigt halten sich in Grenzen. Im Lig ist auch nichts auffälliges.
Muss ich hierfür logging aufdrehen?

Werde mal schauen was freezeMon ist.

Danke für jeden weiteren Tip.

[MadMax-FHEM]

Ich denke Events schauen (Eventmonitor) bzw. DOIF-Tools ist ein guter Weg.
Komisch, wenn nicht viel los ist bzgl. Events.

Weil hohe Last wäre entweder viele Events, die es "gleichzeitig" zu verarbeiten gibt...
...oder aber ein Event bzw. Eventverarbeitung (kann bzw. kommt verm. "von dir", z.B. myUtils oder innerhalb notify/DOIF etc.) die eine "Schleife" dreht, also ganz viel(, ganz schnell) abarbeiten muss...
Evtl. mal schauen, ob nach/bei einem bestimmten Event die Last hochgeht...

Also Eventmonitor und htop parallel kucken...

Daher denke ich wird Freezemon u.U. wenig helfen.
Da hier eher ermittelt wird, wenn fhem wegen "warten auf was (externes)" nicht weiterarbeitet...
...und da ist der fhem Prozess eher "idle" als 100% ausgelastet...
Oder bin ich falsch?

Aber für Blockaden in fhem ist freezemon spitzenklasse!

Gruß, Joachim

[Hackstall]

Danke,

Mal ne dumme Frage gibt es da nicht in FHEM einen Eventcounter der pro Zeit zählt und ggfs. auch für Hochphasen einen Timestamp gibt. Oder sogar bei Max Anzahl die Events loggt. Wäre doch eine coole erwErweitetung des Eventmonitors oder eines Moduls

[MadMax-FHEM]

DOIF-Tools wurde doch (mehrfach) genannt...

Gruß, Joachim

[Sailor]

Ein herzerfrischendes Moiun vom achtern Diek tosammen!

Ich hatte mal einen ähnlichen Fall. Gesucht aber nirgends einen Grund gefunden, warum fhem.pl die htop Liste ständig mit 100% angeführt hat.

Habe dann mal einen Backup der fhem.cfg gemacht und eine jungfräuliche genommen.
Erwartungsgemäß wieder bei 0% gelandet.
Dann nach und nach einzelne Sektionen vom Backup rüber gezogen bis die Auslastung wieder auf 100% geschnellt und somit der Schuldige identifiziert war.

Gruß
    Sailor