98_FREEZEMON - der bessere PERFMON?

[KölnSolar]

Ich drück dann meine Begesiterung noch einmal mit einem eigenen Zitat aus:

Und nur so als Gedanke: Bei der Vielzahl der Module verliert man mittlerweile ja den Überblick. Ich könnt mir daher eine Integration in SYSMON vorstellen, was man dann als "Kernmodul" von FHEM installiert, also ein Modul wie FHEMWEB oder allowed, was in keiner Installation fehlen sollte.

Grüße Markus

[helmut]

Denkt ihr das Modul ist es wert, in die offizielle Distribution mit aufgenommen zu werden?

Ich drück dann meine Begesiterung noch einmal mit einem eigenen Zitat aus:Grüße Markus
"Ich könnt mir daher eine Integration in SYSMON vorstellen"

Ob als Modul oder als Erweiterung von SYSMON - ich bin auch dafuer.

Gruss Helmut

[Benni]

Ich drück dann meine Begesiterung noch einmal mit einem eigenen Zitat aus:Grüße Markus

Na, ob ein Modul mit vielen Funktionen der Übersicht dienlicher ist, als viele Einzelmodule mit genau definiertem Aufgabenbereich und und Funktionsumfang (Linux-Prinzip), darüber könnte man sicher streiten

gb#

[michael.winkler]

bei einem "get freez" habe ich folgende Log Einträge:

Code Auswählen Erweitern


2018.02.05 14:38:17 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_freezemon.pm line 258.
2018.02.05 14:38:17 1: stacktrace:
2018.02.05 14:38:17 1:     main::__ANON__                      called by ./FHEM/98_freezemon.pm (258)
2018.02.05 14:38:17 1:     main::freezemon_Get                 called by fhem.pl (3510)
2018.02.05 14:38:17 1:     main::CallFn                        called by fhem.pl (1822)
2018.02.05 14:38:17 1:     main::CommandGet                    called by fhem.pl (1172)
2018.02.05 14:38:17 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2495)
2018.02.05 14:38:17 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (848)
2018.02.05 14:38:17 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (535)
2018.02.05 14:38:17 1:     main::FW_Read                       called by fhem.pl (3510)
2018.02.05 14:38:17 1:     main::CallFn                        called by fhem.pl (689)


[KölnSolar]

ALs Ahnungsloser zu stacktrace würde ich auf FHEMWEB tippen  Ist zumindest bei mir der Grund für Freezes, wenn ich das groooooße Logfile aufrufe.

Und ich habe einen weiteren Kandidaten entlarvt. Mich selber  Hab vor Jahren mal mit viel weniger Kenntnissen als heute ein Modul für einen RS422-Bus an USB erstellt(kopiert u. angepasst), frei nach dem Motto "denn sie wissen nicht was sie tun" und mit trial&error lief es dann. Nun werde ich mir mal die Kommunikation genauer ansehen.... Fehlerbild

2018.02.05 14:52:26 1: FreezeMon: freezedetect possible freeze starting at 14:52:23, delay is 3.014 possibly caused by FW_closeInactiveClients(0)

Grüße Markus
PS: Thema nun vielleicht in Sonstiges verschieben anstatt Codeschnipsel ?
Edit: Achso, vielleicht noch wie ich auf das Modul gestoßen bin. Die Freezes waren periodisch im Log sichtbar(was eben genau das ist, was den Vorteil zumindest gegenüber apptime ausmacht). Hab mir dann einfach meine verdächtigen periodischen Devices angeguckt und beim Dritten passte der timestamp vom state mit der Freezes-Logmeldung überein.

[michael.winkler]

ALs Ahnungsloser zu stacktrace würde ich auf FHEMWEB tippen  Ist zumindest bei mir der Grund für Freezes, wenn ich das groooooße Logfile aufrufe.

Und ich habe einen weiteren Kandidaten entlarvt. Mich selber  Hab vor Jahren mal mit viel weniger Kenntnissen als heute ein Modul für einen RS422-Bus an USB erstellt(kopiert u. angepasst), frei nach dem Motto "denn sie wissen nicht was sie tun" und mit trial&error lief es dann. Nun werde ich mir mal die Kommunikation genauer ansehen.... Fehlerbild
Grüße Markus
PS: Thema nun vielleicht in Sonstiges verschieben anstatt Codeschnipsel ?
Edit: Achso, vielleicht noch wie ich auf das Modul gestoßen bin. Die Freezes waren periodisch im Log sichtbar(was eben genau das ist, was den Vorteil zumindest gegenüber apptime ausmacht). Hab mir dann einfach meine verdächtigen periodischen Devices angeguckt und beim Dritten passte der timestamp vom state mit der Freezes-Logmeldung überein.

Wichtig ist eigentlich nur die Zeile

Hier versuchst du eine leere Variable durch split zu bearcheiten.

Code Auswählen Erweitern


PERL WARNING: Use of uninitialized value in split at ./FHEM/98_freezemon.pm line 258.


[KernSani]

bei einem "get freez" habe ich folgende Log Einträge:

Code Auswählen Erweitern


2018.02.05 14:38:17 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_freezemon.pm line 258.

[/quote]
Spontan würde ich jetzt sagen, du hast noch keinen freeze... Aber ich schaue heute Abend mal ins Coding und fixe das...

[KernSani]

Folgende Meldung kommt bei einem reload 98_freezemon.pm:

Code Auswählen Erweitern

Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 379.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 380.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 381.

Reicht ein reload nicht aus, muss ein neustart gemacht werden...?

#####EDIT 1

Code Auswählen Erweitern

2018.02.05 08:10:01.654 1: PERL WARNING: Subroutine freezemon_Initialize redefined at ./FHEM/98_freezemon.pm line 67.
2018.02.05 08:10:01.655 1: PERL WARNING: Subroutine freezemon_Define redefined at ./FHEM/98_freezemon.pm line 90.
2018.02.05 08:10:01.655 1: PERL WARNING: Subroutine freezemon_Undefine redefined at ./FHEM/98_freezemon.pm line 123.
2018.02.05 08:10:01.657 1: PERL WARNING: Subroutine freezemon_ProcessTimer redefined at ./FHEM/98_freezemon.pm line 134.
2018.02.05 08:10:01.658 1: PERL WARNING: Subroutine freezemon_Get redefined at ./FHEM/98_freezemon.pm line 242.
2018.02.05 08:10:01.659 1: PERL WARNING: Subroutine freezemon_Attr redefined at ./FHEM/98_freezemon.pm line 272.

Grüße Marcel

Hat ein Neustart geholfen? Eigentlich sollte ein reload ausreichend sein... Dass die %prioQueues nicht bekannt sind ist etwas verwirrend, da diese in der Tat aus den Untiefen von FHEM kommen...

[KernSani]

Neue Version im ersten Post

[willybauss]

Klingt interessant.

Kleine Rückfrage: Ich kann mich erinnern, mal Perfmon benutzt zu haben, finde aber nichts mehr davon in meiner Konfig, weder im UI noch in der fhem.cfg. Dennoch sehe ich im Log nun z.B.

Code Auswählen Erweitern

2018.02.05 21:57:33 1: Perfmon: possible freeze starting at 21:57:31, delay is 2.921
2018.02.05 21:57:33 1: FreezeMon: myFreezemon possible freeze starting at 21:57:31, delay is 2.925 possibly caused by perfmon_ProcessTimer(N/A) CO20_poll(Zuluft_co20) CUL_HM_procQs(CUL_HM_procQs)


Offenbar läuft Perfmon doch noch. Wie kann ich es stoppen?

[KernSani]

Offenbar läuft Perfmon doch noch. Wie kann ich es stoppen?

die Datei 99_PERFMON aus dem /FHEM-Verzeichnis entfernen (oder umbenennen).

[KernSani]

So. eingecheckt. FREEZEMON wird ab morgen mit dem FHEM update verteilt. Wer's eiliger hat: Ich habe die eingecheckte Version im ersten Post aktualisiert.

Ich mache dann hier mal zu. Weiter geht es hier: https://forum.fhem.de/index.php/topic,83909.0.html

[Motivierte linke Hände]

Danke, ein sehr praktisches Modul - bin gerade drüber gestolpert, als es "plötzlich" mit dem Update kam. Habe es gegen perfmon eingetauscht. Mal schauen, was ich so finde.

[MichaelT]

Danke fürs Modul.
Hab von perfmon auf freezemon umgestellt.
Bisher nichts auffälliges.

Gruß
Michael

[KernSani]

Upd. Vergessen den Thread zu zu machen. Alles weitere bitte hier:  https://forum.fhem.de/index.php/topic,83909.0.html