Neues Modul: Performance Monitor

[Harald]

Hallo herrmannj,

ist es sehr aufwendig, Dein Modul so zu ändern, dass das zusätzlich das verursachende Modul mit ausgegeben wird, auch wenn das etwas mehr Resourcen benötigt?

Setzt man verbose auf hohe Werte (z.B. 5), werden von den entsprechenden Modulen u.U. sehr viele Logausgaben erzeugt. Dann ist es m.E. nicht so einfach, die Ausgabe von perfmon zu finden. Gibt es zu der Meldung von perfmon nur eine zusätzliche Zeile mit dem Namen des verursachenden Moduls, ist das doch deutlich übersichtlicher. Dann kann man das entsprechende Modul weiter untersuchen.

Viele Grüße und schönes Wochenende

Harald

[herrmannj]

Hallo Harald,

den Verursacher zu finden ist echte Detektivarbeit. Perfmon führt nur Messungen durch ob alles flutscht. Schau Dir mal apptime an, das wird verwendet um die aktiven Module zu untersuchen. perfmon und apptime sollte man immer als Gespann sehen. Perfmon gibt genaue Aussagen ob und wann Probleme auftreten. Wenn welche da sind liefert apptime statistische Informationen welches Modul wieviel Zeit benötigt.

vg
jörg

[gandy]

Hi,

was ich diesbezüglich unlängst gelernt habe: Perfmon zeigt auf, wann es zu Problemen kommt. apptime kann dann Anhaltspunkte liefern, welche FHEM Funktionen beteiligt sind. Idealerweise findet man damit heraus, wie sich das ungünstige zeitliche Verhalten provozieren lässt. Wenn man es schafft, das mit einem Fhem Kommando zu reproduzieren, kann man direkt davor verbose auf 5 und direkt danach zurück auf 0 setzen.

Im Notfall kann man auch mit 'attr .+ verbose 5; CMD; deleteattr .+ verbose' für ordentlich Lektüre sorgen

Und selbst dann kann es nötig sein, im Modulcode zusätzliche Log-einträge einzufügen, um der eigentlichen Ursache auf den Grund zu kommen. Spätestens hier kann es sich dann lohnen, den Modulautor mit den nötigen Informationen zur Fehlersuche zu kontaktieren.

Grüße,
Andy.

[justme1968]

Vorsicht mit

Code Auswählen Erweitern

deleteattr .+ verbose

ich meine mich zu erinnern das es probleme gib wenn das verbose attribut von global weg ist.

gruss
  andre

[gandy]

ok, ich habe das zwar die letzten Tage recht häufig genauso gemacht, habe aber die Information unterschlagen, dass nein Script davor alle gesetzen verbose Einstellungen gesichert und nach dem deleteattr wieder hergestellt hat. Zumindest kurzzeitig hat das fehlende global verbose nichts ausgemacht.

Grüße,
Andy.

[Harald]

Vielen Dank für Eure Hinweise. Da werde ich mich mal drangeben und versuchen die Ursachen für die Verzögerungen zu finden.

Besten Dank nochmals und schönes Wochenende

Harald

[RoBra81]

Hallo,

da meine (Licht-)Schalter immer mal wieder auf sich warten lassen, wollte ich versuchen, mein System mit Perfmon zu analysieren und zu optimieren. Dabei komme ich jetzt nicht weiter und hoffe, es kann mit jemand einen Anhaltspunkt geben, wo ich weiter suchen kann. Da ich im Log sehr viele Einträge der Form

Code Auswählen Erweitern

2014.12.01 14:31:34 1: Perfmon: possible freeze starting at 14:31:33, delay is 1.879

habe, dachte ich mir, ich drehe mal das Verbose auf 5 und sehe mir an, in welchem Zusammenhang diese Einträge kommen. Erstaunlicherweise kommen diese aber nicht mehr, sobald das Verbose auf 5 läuft. Also habe ich mal eine Excel-Auswertung meines Logs gemacht: Zwischen 00:00 und 13:00 auf Verbose 2 ca. 580 mal Freeze. Zwischen 13:00 und 14:30 auf Verbose 5 genau 4 mal Freeze. Nach dem Rücksetzten auf Verbose 2 gleich wieder 6 Freeze in 3 Minuten.
Noch eine andere Besonderheit ist mir aufgefallen: von den ca. 600 mal Freeze im Log beträgt der Abstand zwischen zwei aufeinanderfolgenden Freezes ca. 490 mal genau 00:01:03 (1 Minute und 3 Sekunden). Da wird scheinbar etwas alle 1 Minute 3 Sekunden ausgeführt, was zu einem Freeze führt? Der Freeze beträgt meistens ca. 3 Sekunden - vielleicht wird da auch etwas minütlich ausgeführt? Wie bekomme ich heraus, worum es sich dabei handelt, wenn ein Verbose 5 zu keinem Freeze mehr führt?

Vielen Dank
Ronny

[gandy]

Exakt dieses Muster (alle 63 Sekunden 3 Sekunden Freeze) hatte ich einmal als beim In-Rente-Schicken eines alten Rechners vergessen hatte, dass mein FHEM immer noch versuchte, einen dort angeschlossenen HM-USB über hmland anzusprechen. Das HMLAN Modul hat dann mit 3 Sek. timeout alle 60 Sek versucht, die Verbindung aufzubauen. Wenn Du nicht den gleichen Fehler machst, schau trotzdem mal, ob Du im lokalen Netz einen Dienst nutzt, die zugehörige IP-Adresse aber nicht erreichbar ist.

Ist alles ein wenig wie Fischen im Trüben, aber vielleicht hilft das ja weiter...

Grüße,
Andy.

[RoBra81]

Das scheint ein Anhaltspunkt zu sein: ich nutze den hmland, allerdings läuft der auf der gleichen Rechner und wird vom HMLAN Modul mit 127.0.0.1 angesprochen

[hexenmeister]

Hast du mit apptime versucht?

[RoBra81]

Ich habe den Übeltäter gefunden: beim STV-Modul das Attribut fork auf enable gesetzt und schon sind die Freezes verschwunden

[Navigator]

...ist es Möglich die Zeitschwelle bis der Monitor "anspringt" zu vergrössern und damit nur bei sehr groben Hängern einen Log zu erzeugen?

[cotecmania]

Nach dem reinkopieren ins Module-Verzeichnis und restart von FHEM kommt folgendes im Log :

2016.02.23 18:08:00 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
2016.02.23 18:08:00 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.

Gruss
Joe

[dev0]

Das hat aber nichts mit perfmon zu tun.

[cotecmania]

OK stimmt, die Funktionen kommen da drin gar nicht vor.
Habe es halt erst bekommen seit ich Perfmon reinkopiert habe.
Allerdings habe ich auch apptime zum ersten mal verwendet.