Hohe CPU-Last

[jp2008]

Nun habe ich seit Heute wieder das Problem, dass die Logic_Queue bis auf über 1000 anschwillt.

Ich schließe mich mal an (auch wenn mein Edomi deutlich einfacher ist)... Ich habe jetzt mehrfach nach kleinen Logikänderungen unter 1.57 eine CPU-Last von 100% wegen Logic_Queue erreicht - erst nach Deaktivierung der zuletzt geänderten Logik-Seiten ging die CPU-Last wieder runter. Auch das heutige Update auf 1.58 konnte nicht helfen.
Aber nach einen Neustart wegen geänderter Basis-Einstellung bin ich jetzt wieder im grünen Bereich (ca. 20%, wobei meine normal CPU-Last eigentlich bisher bei unter 10% lag) - ich konnte jetzt auch auch wieder LogikÄnderungen per Projektaktivierung umsetzen ohne anhaltenden Anstieg der CPU Last.

Eine Aufschlüsselung der verantwortlichen Logik(seite) wäre zur Fehlersuche hilfreich.

[hartwigm]

Nachdem ich die Queue nicht kleiner bekomme, bin ich auf eine Sicherung von vor 2 Wochen zurück als alles noch gut lief.

Ergebnisie Queue läuft auch hier voll.

Da Edomi unter Hyper-V läuft einfach mal nicht so geizig die Ressourcen angepasst und statt 4GB mit 2 CPU´s mal 8GB RAM und 4 CPU zugewiesen.

Ergebnis CPU Last halbiert sich, die LogicQueue wächst nun auf 1903 an.

Echter Mehrwert:
Wenn die Verwandschaft klingelt bekomme ich das Signal erst nach 5min und alles ist gut!


Ich stelle die Fragen nochmals, in der Hoffnung, dass jemand eine Antwort kennt!

Kann ich in mysql den Inhalt der LogicQueue auslesen.

Ich bin mir sicher, dass ich irgendwo einen Bug habe, aber wo!

ed1.PNG

[gaert]

Sieht sehr nach einer Logikschleife aus... Das Auslesen per SQL wird Dich da auch nicht weiterbringen. Ich würde mal das iKO-Logging aktivieren und die Logiken prüfen.

[jp2008]

Sieht sehr nach einer Logikschleife aus...

Eine Logikschleife kann ich jetzt eigentlich ausschließen. Zumindest habe gerade als einzige Änderung eine Ausgangsbox (ohne vorgeschaltete Logik oder Bausteine) ausgetauscht - statt der Ausgangsbox ungleich leer jetzt die Ausgangsbox ungleich 0. Nach der Aktivierung hing der CPU wieder bei 100% fest. Das habe ich mir dann ein paar Minuten angesehen und dann den Server neugestartet (über den Button "Server neustarten"). Nach diesem Neustart ist wieder alles gut und der CPU bei ca. 20%.

PS: Ich nutze den S900 mit 4GB? RAM.

[hartwigm]

jp2008
ich würde hier eine Logikschleife nicht ausschliessen.

genauso geht das bei mir auch, allerdings reicht hoer das stoppen des edomi und anschliessendem start.

Bei mir triggert hier Temperatur, Regen, Helligkeit oder eine der 2000 Heizungswerte irgendwas, und wenn das zum Zeitpunkt des Starts an/aus oder was immer ist, dann gehts und beim start 5min später nicht mehr, oder wars umgekehrt?

Das macht in meinem Fall die Analyse echt schwer, und wenn ich nur 10 Logiken hätte, wäre das ja einfach zu finden.

Ich habe 3 Edomisysteme am laufen und 2 laufen super, insofern bin ich recht sicher, dass das nicht an edomi liegt, sondern an einem Bug von mir.

ich werde Morgen mal das Logfile aktivieren,

[hx5]

Wenn die LBS-Eingänge rot blinken würden sobald eine bestimmte Triggeranzahl pro Sekunde überschritten wurde und dazu noch in ein Log geschrieben wird, wäre eure Fehlersuche einfach.

Man könnte da auch eine kleine PHP-Funktion bauen, die bei Überschreitung in ein Log schreibt, aber das müsste dann in jeden LBS und die Werks-LBS müsste man gegen Eigene tauschen...

[saegefisch]

In der Basis-Konfig (Abschnitt "Logik")gibt es doch bereits einen Parameter dafür (default: 5000 Interationen) Oder interpretiere ich diesen Parameter falsch? Falls nein: Würde eine deutliche Reduzierung dann nicht auch helfen, dass das System in so einem Fall zumindest benutzbar zu halten für Analysen, weil die betreffenden Logiken abgebrochen werden? Und wenn eine so erkannte Schleife den Weg in das Fehler-Log finden würde, müsste die Suche nach Logik-Schleifen doch recht gezielt machbar sein.

[harry7922]

Hallo zusammen,

bei mir ist immer nur maximal eine Logik aktiv.
In den Zeiten, zu der keine Logik aktiv ist, geht die CPU-Last auch nicht runter.

Ich vermute daher ein anderes Problem dahinter?
Nach dem ein oder anderen Neustart des Servers (auch nicht bei jedem) geht die Last kurz danach wieder auch 2-3% runter - und bleibt dort auch über Tage hinweg.
Erst nach Projektaktivierung/Neustart kann es dann wieder sein, dass sie wieder bei 50-60% bleibt und auch nicht mehr runter geht.
Ich denke es spricht zumindest in meinem Fall vieles gegen die Logiken.

EDOMI_CPU_Last.PNG

Wobei bei mir anscheinend der Mysqld die hauptsächliche Last verursacht:
MYSQLD.png

Grüße
Hardy

[hartwigm]

Ich würde mal das iKO-Logging aktivieren

Wo kann ich das aktivieren?

In der Basis_konfiguration finde ich nur die KNX-Protokollierung

[gaert]

Hier:

# Monitor-Logs
#    Hier werden u.a. alle Wertänderungen von Kommunikationsobjekten protokolliert.
#    0 = deaktiviert (diese Einstellung hat Priorität gegenüber dem System-KO[6])
#    1 = Text-Format
#    2 = HTML-Format
global_logMonEnabled=2

...und das Sys-KO Nr. 6 ist entsprechend zu setzen.

[hartwigm]

gaert
aber das sehe ich doch nur KNX-KO´s e3.PNG

[jonofe]

Wobei bei mir anscheinend der Mysqld die hauptsächliche Last verursacht:

Hohe mysql Last wäre aber auch bei einer Logikschleife typisch.
Setzt du neben den EDOMI LBS auch andere User-LBS ein?
Lass dir mal in der 'top' Ansicht den gesamten Befehl anzeigen ('c' drücken und Fenster auf voll Breite ziehen). Insbesondere der php Prozess mit den 26% könnte da beteiligt sein.
Dies könnte einer der EDOMI php Prozesse sein oder ein EXEC User LBS.

EDIT: ggf. solltest du auch nochmal prüfen, ob die Verwendung eines falschen Ausgangs-LBS für die hohe Last verantwortlich sein (siehe dein Problem mit den remanenten Daten)

[harry7922]

Hallo André,

ich verwende auch User-LBS.
Anbei ein neuer Screenshot - leider kann ich das Ergebnis nicht deuten - außer dass eine Logik wohl die PHP-Instanz beschäftigt?
Aber müsste dann nicht die CPU-Last runter gehen, wenn EDOMI im Monitor keine aktive Logik ausweist (Screenshot vorheriger Post).

MYSQLD.png

Danke für die Hilfe.

Grüße
Hardy

[jonofe]

Es deutet zumindest daraufhin, dass die Ursache nicht in einem User EXEC LBS liegt, sondern eher in deiner EDOMI Logik.
Was zeigt denn das erste Widget rechts von der EDOMI Admin Oberfläche? Dort stehen ja die zuletzt getriggerten iKO und KNX GAs.
Ggf. kann man dort erkennen, ob immer wieder dasselbe iKO/GA getriggert wird. Dann sollte es ziemlich weit oben stehen und der Aktualitätsbalken sollte immer voll sein.

[harry7922]

Vielen Dank für die Hilfe,
ich habe meinen Fehler gefunden
Es war eine Logikschleife - ein iKO wurde dadurch sekündlich im Wechsel auf 1/0 gesetzt.

Das Vorgehen von André hat mir geholfen.

Merci und Grüße
Hardy