Hallo zusammen,
ich beobachte in letzter unschöne Verzögerungen zwischen dem Betätigen eines Schalters und dem Aufleuchten einer Lampe.
Auch das Webfrontend reagiert relativ zäh.
Mal eben den room wecchseln und dort einen link betätigen ist nicht.
Ich bin aus diesem Grund schon von einem Raspi 3 auf einen Intel NUC mit einem core i3 umgestiegen
und bevor ich jetzt die Cray XC40 aus dem Regal hohle, wollte ich mal nachfragen, ob man das nicht mit Bordmitteln wieder hinbekommen kann.
Prämisse: es darf kein zeitlicher Unterschied zwischen einer klassischen Elektroinstallation und dem Betätigen eine EnOcean Wandtasters und der Reaktion eine Philips HUE Lampe geben, sonst ist ganz schell die Akzeptanz im Keller.
Da ich mir nicht vorstellen kann, dass ein gepflegtes FHEM einen Core i3 auslasten kann, muss es wohl an etwas anderem liegen.
Ich habe vor einiger Zeit ZoneMinder v1.30.4 drauf installiert, wobei ich derzeit nur das Anordnen der Kamerabilder nutze und keine Bewegungserkennung oder Aufzeichnung.
Zumindest ist mir das nicht bewusst ;-)
Somit ergeben sich 2 Fragen:
1.) wie kann man unter einem Linux (ubuntu 16.04LTS, ständig aktualisiert) mögliche Performancefresser dingfest machen?
Am schönst wäre die CPU-Auslastung aller Prozesse über mehrere Stunden zu loggen.
2.) Ist FHEM echtzeitfähig, oder kann man zumindest notifys irgendwie mit einer höheren Priorität laufen lassen?
Schließlich ist das Loggen von z.B. Temperaturen nicht so zeitkritsch, wie das Schalten von Licht.
Was eine unterschiedliche Priorisierung zumindest naheliegend machen würde.
Irgend ein schickes Attribut, um das Ganze in meinem Sinne zu beeinflussen?
Gruß
Markus
Zitat von: MarkusAutomaticus am 17 Januar 2018, 13:19:33
Somit ergeben sich 2 Fragen:
1.) wie kann man unter einem Linux (ubuntu 16.04LTS, ständig aktualisiert) mögliche Performancefresser dingfest machen?
Am schönst wäre die CPU-Auslastung aller Prozesse über mehrere Stunden zu loggen.
Perfmon würde für fhem gehen, da siehst du dann wann fhem blockiert (siehe 2.).
Wenn du da viel hast, dann mit apptime...
Es gibt das Modul SysMon zur "Abfrage" genau dieser Werte.
Aber: es wird minütlich aufgerufen und macht somit wohl für CPU-Auslastung keinen Sinn.
Ein häufigerer Aufruf erzeugt (ein wenig?!) zusätzliche Last, also auch fraglich...
Zitat von: MarkusAutomaticus am 17 Januar 2018, 13:19:33
Somit ergeben sich 2 Fragen:
2.) Ist FHEM echtzeitfähig, oder kann man zumindest notifys irgendwie mit einer höheren Priorität laufen lassen?
Schließlich ist das Loggen von z.B. Temperaturen nicht so zeitkritsch, wie das Schalten von Licht.
Was eine unterschiedliche Priorisierung zumindest naheliegend machen würde.
fhem läuft in EINEM Thread!
Also alles schön brav nacheinander...
Ausnahme: nonBlocking-Aufrufe die per NonBlocking.pm "ausgelagert" sind/werden.
Muss aber "extra programmiert" werden...
Gruß, Joachim
Mit einem Raspi hatte ich das auch, da kommt je nach Abhängigkeiten die abgearbeitet werden einiges zusammen. Bei einem i3 darf das nicht vorkommen - Fhem schafft in Kombi mit SQL und diversen Dockern auf einem N3150 nicht mal ansatzweise das Schaffen einer signifikanten Load.
Mal stumpf TOP ausprobiert, gedrückt, und geschaut ob und wie sich die Load verscheibt. Bei Intel-CPUs empfehle ich Dir PowerTop (https://wiki.ubuntuusers.de/PowerTOP/ (https://wiki.ubuntuusers.de/PowerTOP/))
Verzögerungen (Freeze) sind in der Regel _nicht_ das Resultat von fehlender CPU Leistung sondern das Ergebnis einzelner Module (ihrer Architektur) und eigenen Codes.
Mit perfmon und apptime die Suche starten https://wiki.fhem.de/wiki/Apptime
Hallo zusammen,
vielen lieben Dank für euere Tipps.
Jetzt hab ich Stoff zum Testen.
Gruß
Markus
Die Regel kann aber Ausnahmen haben ;) Z.B. wenn von einem Event ausgehend mehrere Bedingungen geprüft werden, Berechnungen angestellt werden, Abhängigkeiten in Modulen abgearbeitet werden müssen. Denn steigt die Auslastung signifikant, da ja alles nur in einem Thread läuft - im dem eben u.U. gerade mehrere von der Aktion unabhängige Aktionen (Notifies, DoIfs, ATsetc...) in der Warteschlange stehen. Und wenn der Thread um X % schneller arbeitet reduziert sich die Verzögerung ;) Mein Raspi ist bei komplexen Schaltaufgaben mit mehreren Abhängigkeiten an die Wand gelaufen, was sich eben simpel per Monitoring der Load von Perl zeigt (Average meinetwegen bei 2.15 0.51 0.23). Das kann man schnell erkennen wenn man die Aktion mehrfach auslöst und sich das anschaut.
Beispiel: gleiche fhem.cfg, alles analog (simpler Umzug der Installation). Ein Intertechno Bewegungsmelder sollte eine Hue-Gruppe steuern. Auf dem Raspi 3-5 Sekunden Delay, auf dem N3150 instant...