SYSMON: FHEM hängt bei Start, wenn SYSMON-Attribut disable=1 gesetzt ist

gandy · 12 Oktober 2014, 17:33:25

Aktuell suche ich nach Gründen für einen regelmässigen Anstieg der FHEM-Latenz jede Minute. Zu dem Zweck habe ich verschiedene Dienste per Attribut disable=1 deaktiviert. Bei einem Neustart hing FHEM dann plötzlich reproduzierbar in der Startup-Sequenz fest und ließ sich jeweils nur noch per kill $PID beenden. Nach längerer Suche stellte sich heraus, dass dafür das gesetzte Attribut disable=1 in der Instanz des Moduls SYSMON (v1.8.7) verantwortlich war.

Beobachtet habe ich das auf einem Cubietruck mit folgender Konfiguration

Code Auswählen


define sysmon SYSMON
attr sysmon filesystems fs_root:/:Root
attr sysmon disable 1

Kann das jemand reproduzieren?

Grüße,
Andy.

hexenmeister · 12 Oktober 2014, 23:15:40

Kann ich, eine schöne Endlosschleife

Danke fürs Finden, werde ich reparieren. Kommt morgen per update.

Zu der Latenz... da ist SYSMON vermutlich unschuldig. Ich habe ihn länger per apptime beobachtet, normalerweise verbrät es nicht mehr als 300-700 mS am Stück.
Konnte apptime Dich bei der Suche nicht weiterbringen?

Grüße,

Alexander

gandy · 12 Oktober 2014, 23:35:15

Cool, teste ich morgen, danke fürs rasche Beheben! Apptime kannte ich noch nicht, danke für den Tipp!

Grüße,
Andy.

hexenmeister · 12 Oktober 2014, 23:43:15

Na dann gebe ich noch eine Empfehlung ab

http://forum.fhem.de/index.php/topic,16347.0.html

hexenmeister · 13 Oktober 2014, 00:22:25

Noch was, vielleicht hilft...
Ich habe vor gar nicht langer Zeit auch Probleme mit Antwortzeiten und Stabilität gehabt. Zum Einem war 1wire problematisch, was sich allerdings mit dem Umstieg auf OWX_ASYNC erledigt hat. Und dann noch Geodata riß manchmal den Server runter. Habe ich rausgenommen, seitdem läuft FHEM wieder tagelang ohne Hänger und Abstürze

gandy · 13 Oktober 2014, 08:14:21

apptime hat's gefunden

Bei mir war es eine alte HMUSB Definition, die auf eine Rechner zugriff, den ich vor einigen Tagen (nach Umzug von FHEM) abgeschaltet habe. Solange der Rechner noch lief und auf dem Port kein Service erreichbar war, gab es kein Problem, nachdem aber auch die IP verschwunden war, kam es wohl zu dem gut 3-sekündigen Delay, und das alle 60 Sekunden

Die verbleibenden Problemkinder sind Nofities, die Emails per sendmail versenden, aber das ist wenigstens nicht allzu häufig der Fall.

perfmon werde ich mir anschauen, klingt nach einem guten Add-on für FHEM.

Und ja, SYSMON liegt auch bei mir bei 602max und 531avg. Ließe sich das durch ein fork noch optimieren?

Nochmals vielen Dank,
Andy.

hexenmeister · 13 Oktober 2014, 08:17:42

ZitatLieße sich das durch ein fork noch optimieren?

Ja, vielleicht, müsste ich mir ansehen. Habe aber bis jetzt nicht als Problem empfunden.
Hast Du einen guten Beispiel für so eine Implementierung?

gandy · 13 Oktober 2014, 12:06:08

Stimmt schon, ein wirkliches Problem ist es nicht, andererseits hat SYSMON in apptime immer die Pole Position inne - bis ich per Structure alle Rollos fahren lasse, aber das ist wohl ein anderes Thema

Manche Module setzen wohl Blocking.pm ein, um blockierende Aufgaben in einen Child-Prozess auszulagern, eigene Erfahrungen habe ich damit aber nicht gemacht. Das Modul 98_update verwendet das z.B. im Zusammenhang mit dem Attribut updateInBackground.