Lokale Console mit hoher CPU Last

Ich habe aktuell auch mal paar Messungen gemacht. Also bei mir sieht das auch so aus als wäre die Last recht hoch. Ich habe aktuell einige Messungen eingebaut, aber am ApplyData liegt es nicht direkt, da die Funktion selber nur ca. 0,15-0,20 Sekunden braucht und dann dauert es wieder 15 Sekunde (default) wieder schläft.

Keine Ahnung was dein Modul genau macht, was IPS aktuell nicht mag.
Was man aber vermeiden sollte, da es auch zu allen WebFronts und IPSView gepuscht wird, sind Updates von Objekten.
Auch wenn sich nichts geändert hat, so wird z.b. bei SetName, SetPosition, SetIcon, den Profilen usw. jedesmal ein Refresh ausgelöst.
Falls etwas davon hier die Ursache ist, so könnte man das mit einer Abfrage vorher ja abfangen.
Ich selber hatte schon mal den Designer von IPSView mit SetPosition lahmgelegt :wink:
Michael

Ja das war eins was ich meinte!

Aber die Prüfung ob sich etwas geändert hat wäre imho besser im Symcon selber, weil ob jedes Plugin das selber tut oder Symcon selber da finde ich ich das aber besser.

Außerdem ist das Problem ja noch recht neu, denn das Dauerupdate pro Lauf habe ich schon immer drinne.

Würde mal gerne wissen was paresy dazu sagt.

Die Prüfung ob etwas existiert oder ein Update benötigt solltest du im Modul vornehmen. Ansonsten ist es, wie Nall Chan sagte… IP-Symcon führt aus, was du wünscht und propagiert es entsprechend als Aktualisierung. Das kann sehr gut die CPU Last erklären.

paresy

Also das meiste prüfe ich schon vorab. Lediglich die Position, Icon und Visiblity werden entsprechend der HUE Bridge Response angepasst. Das habe ich jetzt mal abgeschaltet, zumindest soweit ich das konnte ohne das Plugin unbrauchbar zu machen :smiley:

Jetzt müssten die Betroffenen mal testen ob das reicht.

Hallo traxanos,

danke für deine Mühe und entschuldige bitte die späte Reaktion, bin erst jetzt dazu gekommen.

Zumindest bei mir hat sich eine Veränderung ergeben. Dafür, dass nur dein HUE Modul aktiv ist und sonst nichts, ist die Last natürlich immer noch erstaunlich hoch. Zumindest bei Einsatz der 4.1 Konsole.

Server Konsole Update CPU Last
4.1 4.1 aktiv ca 60%
4.1 4.0 aktiv < 10%

Gruß
Ralla

Mehr kann ich leider nicht ändern, denn sonst würde das Plugin nicht mehr gehen. Dann muss Symcon wieder effizienter werden…

Ich habe mal auf meinem Testsystem eigenmächtig folgende Änderungen in der „ApplyData“ gemacht.

    if (@$briId && GetValueInteger($briId) != $values['bri']) SetValueInteger($briId, $values['bri']);
    if (@$satId && GetValueInteger($satId) != $values['sat']) SetValueInteger($satId, $values['sat']);
    if (@$hueId && GetValueInteger($hueId) != $values['hue']) SetValueInteger($hueId, $values['hue']);
    if (@$ctId && GetValueInteger($ctId) != $values['ct']) SetValueInteger($ctId, $values['ct']);

    $colorModes = array(
      'xy' => 0,
      'hs' => 0,
      'ct' => 1
    );
    if(GetValueInteger($cmId) != $colorModes[$values['colormode']]) {
      switch (@$values['colormode']) {
        case 'xy':
        case 'hs':
          $hex = $this->HSV2HEX($values['hue'], $values['sat'], $values['bri']);
          SetValueInteger($colorId, hexdec($hex));
          IPS_SetHidden($colorId, false);
          IPS_SetHidden($satId, false);
          if (@$ctId) IPS_SetHidden($ctId, true);
            if (@$cmId) SetValueInteger($cmId, 0);
              break;
        case 'ct':
          if(@$colorId) IPS_SetHidden($colorId, true);
          if(@$satId) IPS_SetHidden($satId, true);
          IPS_SetHidden($ctId, false);
          SetValueInteger($cmId, 1);
          break;
      }

Danach ist die von der 4.1 Konsole verursachte CPU Last von konstant ca. 80% auf auf- und abschwellende Werte von max. 38% zurückgegangen. Die Funktion des Moduls scheint von den Änderungen unbeeinflusst zu sein.

Der Zustand (‚STATE‘) der Lampen wird weiterhin bei jeder Statussynchronisation aktualisiert. Wo dies geschieht hab ich noch nicht gefunden. Auch weiß ich nicht, welche Objekteigenschaften im Hintergrund ein Update erfahren, obwohl es eigentlich nicht notwendig wäre.

Es scheint auf alle Fälle sinnvoll zu sein, ein Update nur dann durchzuführen, wenn es tatsächlich Änderungen gibt.

Es bleibt natürlich die Frage, warum die 4.1 Konsole mit häufigen Updates mehr zu kämpfen hat als die 4.0 Konsole.

Gruß
Ralla

Nein ein Update sollte immer durchgeführt, wenn es um Zustände geht! Sonst stimmen die Statistiken z.B. auch nicht mehr. Also sollte Symcon schon Probleme mit dem Speichern von Messwerten haben, dann mache ich mir echt Sorgen. Damit meine ich jetzt nicht Strukturupdates, die sollten wenn möglich nur bei Änderungen durchgeführt werden.

EDIT:
Deine Änderungen funktionieren nur wenn man die Daten auch nur über Symcon pflegt. Sobald die HUE Bridge durch andere Plugins genutzt werden, wird der Status nicht zuverläßig abgeglichen. Das geht imho garnicht. Wie gesagt, wenn ich Messwerte (Zustände) erheben, dann gehören die auch gespeichert. Sonst kann man den Statussync auch abschalten…

Warum, wenn sich nichts geändert hat? Ich möchte dich nicht provozieren, die Frage ist wirklich ernst gemeint.

Die Daten werden doch sowieso nur bei Änderungen in die Datenbank geschrieben. Oder habe ich bisher etwas falsch verstanden?

Wie meinst du das? Ich kann die Lampen sowohl über Symcon als auch über die HUE Android App steuern und die Daten werden in beide Richtungen korrekt abgeglichen.

Gruß
Ralla

EDIT:

Also sollte Symcon schon Probleme mit dem Speichern von Messwerten haben, dann mache ich mir echt Sorgen.

Die Sorge teile ich nicht. Es ist ja nicht der Serverprozess der Probleme hat, sondern die Konsole, die, aus welchen Gründen auch immer, scheinbar mit der Aufbereitung der Daten nicht mitkommt.

Doch wenn man wie ich Auswertungen durchführt schon. Z.B. wenn man Durchschnittswerte ermittelt, ist es wichtig alle Messpunkte zu haben, sonst stimmen die Statistiken nicht. Auch wenn ich bei HUE Lampen das weniger tue bzw. nicht mit jedem Wert.

Nein, Symcon schreibt jeden Messwert weg und kann dann unterscheiden zwischen -> Änderung und Aktualisierung. Und diese Logik will ich nicht umgehen.

Können Sie nicht, denn der Farbwert wird nicht korrekt abgeglichen, da du diesen nur berechnest wenn man den ColorMode wechselt. Auch dürfte bei der Ersteinrichtung deine Version nicht alles korrekt anlegen.

Generell bin ich jemand der sagt, wenn ich einen Messpunkt habe, soll dieser nicht „verworfen“ werden. Meiner Meinung nach ist das dann ein Bug in Symcon. Den Symcon muss mit dem Schreiben von Zuständen klar kommen. Stell die mal vor man würde nur bei Änderung Daten weg schreiben, so würde bei einem Homematictaster z.B. nur der erste Tastendruck funktionieren… Und es mal so und mal so zu machen halte ich auch nicht für geeignet.

Also bei mir landen die Daten nur bei Änderungen in den entsprechenden CSV-Dateien (der Datenbank).

Der Zeitpunkt der letzten Aktualisierung wird, zumindest bei mir, nur in der settings.json gespeichert. Diese wird aber auch nur in einem Intervall geschrieben das größer als die Zeitspanne zwischen zwei Aktualisierungen der HUE-Items ist. Somit gehen auf jeden Fall Daten verloren.

Vielleicht kann das Symcon-Team hier für Klarheit sorgen.

Ich habe neben meiner Testinstallation, auf der ich meine Änderungen durchgeführt habe, auch noch ein System, auf dem ich dein Modul unverändert einsetze. Ich kann tun und lassen was ich will, die Variablen unterscheiden sich immer nur in dem Aktualisierungsdatum, die Werte sind immer identisch.

Der angefügte Screenshot zeigt links mein Testsystem und rechts mein System mit dem unveränderten Modul. Der Farbwert wird auch bei Verwendung des unveränderten Moduls nicht immer aktualisiert.

Neuanlage aller Items habe ich tatsächlich noch nicht ausprobiert.

Gruß
Ralla

P.S.
Ich glaube, so langsam wird es hier OT.

Wir sind an der Problematik dran. Habt bitte noch etwas Geduld. Ich gebe Bescheid, sobald wir die genau Ursache bzw. Fix haben sollten :slight_smile:

paresy

Danke für die Info paresy.

Hab ich die Datenspeicherung richtig wiedergegeben?

Wenn hundert Messwerte im Sekundentakt aktualisiert werden, belastet das die Verbindung zur Konsole und somit eben auch die CPU. Aber wird reden wie gesagt um viele Messwerte pro Sekunde. Wenn du jedoch jede Sekunde Objekte erstellst, sieht das schon anders aus. Pro erstellen einer Variable gibt es X Events, die gefeuert werden und abgearbeitet werden. Vermutlich wird einer davon in der neuen Konsole nicht optimal gelöst sein und dadurch viel CPU Zeit kosten.

Wir loggen alle Änderungen auf die Festplatte. Wir beachten während der Laufzeit auch alle Aktualisierungen, um den die Länge des Zustands eines Wertes korrekt ermitteln zu können. Wir speichern die Zeiten wann etwas Aktualisiert wurde aber nicht explizit. Nur die Zeit der Änderungen.

Es ist somit auf jeden Fall vollkommen OK alle Aktualisierungen per SetValue zu schreiben, es sei denn es passiert im Millisekundentakt. Dann würde ich dies ggf. reduzieren, um das System nicht zu belasten.

Die Settings wird auch beim Beenden geschrieben. Somit sind die Daten nur bei Abstürzen verloren.

paresy

Danke paresy für die Info! Erstellen tue ich ja nur wenn sich etwas ändert. Vor her habe ich die Position bei jeder Abgleich überschrieben, das habe ich aber schon optimiert.

Ich denke eine Ursache für das Problem gefunden zu haben. Zum nächsten Update ist ein Fix dabei und ich würde mich über Feedback freuen, ob dies euer Problem auch vollständig löst.

paresy

Hallo paresy,

danke für eure Bemühungen.

Es ist tatsächlich eine Verbesserung eingetreten. Allerdings besteht immer noch ein erheblicher Unterschied zur 4.0 Konsole.

Die Testbedingungen sind wie bisher:

[ul]„Nackte“ Installation des 4.1 beta Servers auf Raspberry 3
[/ul]

[ul]Installation des unveränderten HUE Moduls
[/ul]

[ul]=> 66 Variablen
[/ul]

Server Konsole Update CPU Last
4.1-539 entsprechend aktiv bis zu 40%
4.1-539 4.0 aktiv bis zu 9%

Zum zusätzlichen Vergleich die Daten meines aktiven Systems:

[ul]symcon 4.0-424 auf Raspberry 2B
[/ul]

[ul]5 IO-Instanzen (Homematic, HUE, Logitech Media Server, MQTT, Client Socket)
[/ul]

[ul]2 Splitter Instanzen (IPS-868 Gateway, Logitech Media Server)
[/ul]

[ul]1718 Variablen
[/ul]

Server Konsole Update CPU Last
4.0-424 4.1-539 aktiv bis zu 80%
4.0-424 4.0 aktiv bis zu 12%

Erfreulich ist, dass die aktuelle 4.1 beta Konsole trotz der hohen CPU-Last nicht ins Hintertreffen zu kommen scheint.
Die Aktualisierungszeiten im Meldungsfenster bleiben synchron zur Systemzeit.

Gruß
Ralla

Ich bin leider immer noch nicht dazu gekommen ein detailliertes Profiling zu machen, wodurch die hohe CPU-Last verursacht wird. Ich habe das Thema noch offen - Bitte noch etwas Geduld!

paresy

PS: Vielen Dank für die detaillierte Analyse!

Hallo Paresy!

Gibt es hier schon etwas neues? Leider werkelt meine Konsole noch immer mit sehr hoher CPU Last…

Danke und lg