Projektaktivierung dauert lange

[Su8Ze3O]

Hi zusammen,

seit einiger Zeit ist mir aufgefallen, dass ein Neustart oder auch nur Projektaktivierung zwischen 10 und 15 Minuten Zeit in anspruch nimmt.
bis jetzt hat mich das nicht wirklich gestört, da wenn alles fertig ist auch alles mehr oder weniger funktioniert. Jetzt sind es aber schon ein paar Punkte, so dass ich mir gedanken machen muss.

MIr ist auch aufgefallen, dass bei der Vorbereitung der Projektaktivierung Edomi erstmal diverse Sachen schaltet.... woran könnte das liegen? Ich habe jetzt schon alles durchsucht aber keinen Hinweis auf ... schalte bevor Server neustart...

der folgenden LBS macht auch durchgehend probleme....
Füllen Kammera-Archiv aus DVR 19001422
ggf. ist es auch der Telegram Contact v.1.1 LBS19000303, sobald hier an E5 ein Photo ankommt hagelt es Fehlermeldungen....
Ich spiele eh mit dem Gedanken auf CentOS7 zu gehen, hoffe mal das Problem löst sich dann von alleine…

Aber zurück zum Neustart.
die Prozedur läuft bis zur Fertigstellung des Initscans einwandfrei durch, dann starten die Logic prozesse... ca. 2 Minuten
Sofort startet der Initscan, der alle Adressen zügig abfragt. Ca. 30 Sekunden
Jetzt wird die Logic aktiviert und die Queue füllt sich auf ca. 250 und arbeitet sich auf ca. 200 ab. Ca. 30 Sekunden.

Dann passiert ca. 7-12 Minuten lang nix, also nichts was ich erkenne, von KNX Verbindungsabbrüchen mal abgesehen.
Ist die Wartezeit vorbei springt die Queue auf 700-800 und eine weitere Minute später ist dann die Queue wieder im normalen Bereich und Edomi arbeitet normal.
Wenn ich ALLE Logicseiten deaktiviere besteht das Problem logischerweise nicht. Das Problem ist auch nicht auf eine Logicseite bezogen, habe jede und auch Kombinationen deaktiviert und aktiviert.

Irgendwelche ideen?
Danke für Eure Hilfe

[starwarsfan]

Hi

[FONT=Calibri]
seit einiger Zeit ist mir aufgefallen, dass ein Neustart oder auch nur Projektaktivierung zwischen 10 und 15 Minuten Zeit in anspruch nimmt.

Das kann ich bestätigen, habe hier ein ähnliches Verhalten.

[FONT=Calibri]
MIr ist auch aufgefallen, dass bei der Vorbereitung der Projektaktivierung Edomi erstmal diverse Sachen schaltet.... woran könnte das liegen? Ich habe jetzt schon alles durchsucht aber keinen Hinweis auf ... schalte bevor Server neustart...

Was genau meinst Du mit "schaltet"? Gehen da Telegramme auf den KNX-Bus?

der folgenden LBS macht auch durchgehend probleme....
Füllen Kammera-Archiv aus DVR 19001422
ggf. ist es auch der Telegram Contact v.1.1 LBS19000303, sobald hier an E5 ein Photo ankommt hagelt es Fehlermeldungen....

Habe ich leider nicht in dieser Form in Verwendung, da kann ich nichts dazu sagen.

[FONT=Calibri]
[FONT=Calibri]Ich spiele eh mit dem Gedanken auf CentOS7 zu gehen, hoffe mal das Problem löst sich dann von alleine…

Auf CentOS 7 bin ich schon lange, damit hat das eher nichts zu tun...

Aber zurück zum Neustart.
die Prozedur läuft bis zur Fertigstellung des Initscans einwandfrei durch, dann starten die Logic prozesse... ca. 2 Minuten
Sofort startet der Initscan, der alle Adressen zügig abfragt. Ca. 30 Sekunden

Ack, same here.

[FONT=Calibri]
Jetzt wird die Logic aktiviert und die Queue füllt sich auf ca. 250 und arbeitet sich auf ca. 200 ab. Ca. 30 Sekunden.

Das ist bei mir ziemlich anders. Die Logic-Queue schwillt bei mir auf weit über 3000 (!) Einträge an und zu diesem Zeitpunkt passiert gefühlt gar nichts. Dieser Zustand bleibt dann ca. zwei Minuten so, danach baut sich die Queue in grossen Schritten ab und Edomi läuft normal.

Allerdings ist dieser gefühlte Freeze resp. dessen Dauer wohl sehr stark von der verwendeten Hardware abhängig. Aus diesem Grund läuft Edomi bei mir auch nicht wie ursprünglich geplant auf dem Timberwolf, da der Start dort eine knappe halbe Stunde dauert...

[Su8Ze3O]

Hi Yves,

danke für die schnelle Antwort.
interessant... dann ist dieses Verhalten doch garnicht so ungewöhnlich....

Zitat von starwarsfan
Was genau meinst Du mit "schaltet"? Gehen da Telegramme auf den KNX-Bus?

ja genau, bei jedem Neustart wird bei uns das Haus erleuchtet... 😁 zum Glück nur die Indirekte Beleuchtung im EG.

[givemeone]

Hast du entsprechende SystemKOs in Verwendung? Das sKO 2 könnte sowas machen.
Oder eben das anfragen von Gas durch den Initaxan KÖNNTE Lampen schalten, je nach ETS Konfiguration.

Mein Restart dauert auch ewig, habe daher 2 edomis parallel km Einsatz, die ich über ein zentrales ko umschalten kann. Aber auch nicht optimal. Nun, mich stört es wenig.

Gefühlt wird viel auf MySQL gearbeitet, diese arbeitet bei mir sehr sehr viel. Könnte mir vorstellen, dass man hier bei den indexsn noch etwas optimieren könnte (wie bei den Archiven schon bekannt ist)

[jonofe]

Habr ihr große Datenarchive? Wenn ich mich richtig erinnere, hat das großen Einfluß auf die Startgeschwindigkeit.

[Ing-Dom]

Ich hab das Verhalten auch und hab mein großes Datenarchiv (7,5 GB archivKoData) im Verdacht.
Bin noch auf 1.64.

[saegefisch]

Bei mir hat der Umfang der Datenarchive sehr klar mit der Aktivierung korreliert.
Daher rate ich klar dazu:Nur sinnvoll erforderliche Daten (Tendenz: Kurzzeit oder Langzeit, aber mit edomi-Verdichtung) in edomi für Diagramme. Alles andere aka. Massendaten/granulare Langfristdaten via influxDB + grafana (ggf. in edomi grafana-Diagramme einbinden). So habe ich für mich das beste aus 2 Welten (auch wenn ich lieber nur 1 Welt hätte)...
-> Diagramme mit aktuellen Daten direkt in der Visu meist bis ein paar Tage bis wenige Wochen in edomi, alles andere grafana (nutze ich direkt, nicht eingebettet)

Seit dem sind Aktivierungszeiten kein Thema mehr.

Just my 2 cents

[rdeckard]

Kann auch bestätigen, dass meine Projektaktivierung ewig (5-10 Min.) dauert. Bin auf 2.02 und CentOS7. Habe das Problem aber schon lange und vermute mein seit 2016 überfülltes Datenarchiv (Temperatur-Werte alle 5 Min. und so Zeugs). Bis jetzt leider noch keine Zeit gehabt, das mal sauber zu verdichten oder besser, auszulagern. (Von Diagrammen spreche ich natürlich schon lange nicht mehr.)

Hab mich bisschen an die lange Projektaktivierung gewöhnt. Wenn ich mal was an Logik/Visu ändere, mache ich soviel viel möglich. Alles andere (Tests) wird auf einem Test-System ausprobiert.

Was aber langsam zunehmend wirklich stört, ist die Tatsache, dass ich nun offenbar auch jeweils um Mitternacht eine 5-minütige AUS-Zeit habe, in der ich Edomi nicht steuern kann. Da wir einige Licht-Szenen haben, die via Edomi gesteuert werden, ist das manchmal mühsam. Gerade am Wochenende, wo man durchaus um Mitternacht noch nicht im Bett liegt.
Ich vermute, das hängt mit der täglichen DB-Bereinigung/Maintenance zu tun. (Projekt wird ja glaub nicht um Mitternacht automatisch aktiviert.)
Leider kann man meines Wissens nicht definieren, wann dieser tägliche Edomi-Maintenance-Job läuft. Ich würde dies so gern auf z.B. 2 Uhr oder 3 Uhr morgens setzen. Dann würde es mich wohl weniger stören.

[starwarsfan]

Hi

Leider kann man meines Wissens nicht definieren, wann dieser tägliche Edomi-Maintenance-Job läuft. Ich würde dies so gern auf z.B. 2 Uhr oder 3 Uhr morgens setzen. Dann würde es mich wohl weniger stören.

Ack, das wäre super, wenn sich das konfigurieren lassen könnte. Genau dieses "Problem" habe ich ebenfalls.

[saegefisch]

An dieser Stelle möchte ich aber auch den "Nullpunkt" für alle noch mal gerade rücken, wie es mal war und wie verwöhnt wir sind (erst recht, wenn ich da auch noch an die Zeiten beim homeserver denke)... Mit der nur Sekunden dauernden Visu-Aktivierung (kennt vielleicht noch nicht jeder neue Mitleser hier!) hat Christian die Arbeit an eodmi schon unfassbar vereinfacht, weil man mehr an Visu arbeitet, als am Backend. Das macht man ja eher selten und in geballten Arbeitspaketen und vor allem am Anfang - da sind die Archive eher noch klein. Visu ist aber irgendwie immer...

Vielleicht noch der Hinweis, dass man Datenarchive auch downloaden (edomi) und ggf. auch wieder hochladen kann (LBS). Das schafft auch Optionen, seine Datenmengen zu überarbeiten. Und zu überdenken(!): Edomi/SQL ist keine InfluxDB... erst recht gepaart mit dem unbedingten Sparwillen an der HW bei dem ein oder anderen Thema hier im Forum: Kann ich machen, wenn ich ein schlankes System will. Aber wenn ich viele Daten will, dann muss man auch die HW dafür liefern. Beides zusammen geht nicht. Aber ich weiß, Yves, das ist bei Dir sicher nicht das Thema...

Und für umfangreiche Logik-Arbeiten mit häufigem Aktivierungs-Bedarf ist ein DEV-edomi in einer VM hilfreich: Keinerlei Archive, aber alle KO. Aktivierung dauert nur Sekunden. Und wenn alles sauber funktioniert, LBS veröffentlichen bzw. erprobte Logik im PROD-System nachbauen. Das spart extrem viel Zeit und das Thema Aktivierung rückt noch weiter in den Hintergrund.


ABER natürlich ist ein mehr-minütiger Stillstand - egal aus welchem System-Grund - nicht schön und ein System sollte Wege kennen, dies zu vermeiden

DAHER: Bei einem Multi-Core/Multi-Threat-System wäre es überaus wünschenswert, wenn ein solcher Prozess mit niedriger oder wählbarer Last nebenbei auf anderen Kernen laufen kann und nicht in einer täglichen Hauruck-Aktion. Zudem wäre es gut, wenn bei jeder Aktivierung sollte nach Möglichkeit nur das unbedingt erforderliche vom System bereinigt wird. Alles andere (Verdichtung, etc.) nur 1x täglich. Wenn diese Zeit dann noch wählbar wäre, dann wär's in der Tat noch primaererererer... als Nachtmensch ist Mitternacht für mich noch früher Abend

[starwarsfan]

Hallo miteinander

An dieser Stelle möchte ich aber auch den "Nullpunkt" für alle noch mal gerade rücken, wie es mal war und wie verwöhnt wir sind (erst recht, wenn ich da auch noch an die Zeiten beim homeserver denke)

Vollkommen korrekt, vielen Dank dafür! Ich persönlich habe mich jedoch nie mit dem Homeserver herumgeplagt, da bei mir von vorn herein klar war, dass ich mir dieses Ding nie antun mochte...

Aber wenn ich viele Daten will, dann muss man auch die HW dafür liefern. Beides zusammen geht nicht. Aber ich weiß, Yves, das ist bei Dir sicher nicht das Thema...

Nicht wirklich, nein...

Und für umfangreiche Logik-Arbeiten mit häufigem Aktivierungs-Bedarf ist ein DEV-edomi in einer VM hilfreich

Definitiv! Das habe ich schon von Anfang an so gemacht. Damit kann man beliebig experimentieren, ohne den WAF in den Sturzflug zu bringen.

Nochmals danke für die "Erdung" an dieser Stelle.

[Su8Ze3O]

Hallo Zusammen,

erstmal vielen Dank für die ganzen Antworten.

und vorweg, ich wusste nicht, dass die lange Zeit normal ist und jeder hat, der auch mit vielen Logiken arbeitet. Ich dachte das ist nur bei mir so und hängt auch mit den KNX Verbindungsabbrüchen zusammen....

zu dem Punkt werde ich mich dann wohl näher mit meiner Hardware beschäftigen.
Archive habe ich jedenfalls keine großen.

Danke und Grüße

[Ing-Dom]

Daher rate ich klar dazu:Nur sinnvoll erforderliche Daten (Tendenz: Kurzzeit oder Langzeit, aber mit edomi-Verdichtung) in edomi für Diagramme. Alles andere aka. Massendaten/granulare Langfristdaten via influxDB + grafana (ggf. in edomi grafana-Diagramme einbinden). So habe ich für mich das beste aus 2 Welten (auch wenn ich lieber nur 1 Welt hätte).

Das hört sich gut an.

Hast du ggf. etwas mehr dazu? Gibts schön einfache HowTos / Walkthroughs?
Welche LBS verwendest du?

[starwarsfan]

Hallo miteinander,

nachdem ich für die Beschleunigung der Darstellung nun, wie in einem anderen Thread empfohlen, einen Index in der DB angelegt haben, werden die Diagramme super schnell dargestellt. Die Projektaktivierung verhält sich nun aber noch schlimmer. Beim Start bleibt die Logik-Queue bei ~250 Einträgen für eine ganze Weile stehen und es passiert gefühlt gar nichts. Der Init-Scan ist laut Log an dieser Stelle schon vorüber. Dann geht die Logik-Queue auf knapp 11000 Einträge (!!!) hoch aber ab diesem Zeitpunkt "läuft" Edomi. Sprich, die Logik-Queue wird in ca. 50-100er Schritten abgebaut und auch die Visu's werden aktualisiert resp. mit Live-Werten gefüllt. Damit dauert der Start auch hier über 5 Minuten.

Der Einzige Change ist wie gesagt der Index auf archivKoData via

create index Idx_1 on archivKoData(targetid, datetime);

Damit wurde die Datenmenge auf der Platte aber auch fluffig verdoppelt, was vermutlich obiges Verhalten auslöst, oder?

[Ing-Dom]

Ich hab durch das Löschen alter Einträge (7,5 GiB => 3,2GiB) den Startup deutlich beschleunigt!
Es scheint hier ein direkter Zusammenhang zu bestehen. Wäre nur interessant welcher?

Es scheint das der mysqld beim startup irgendwas macht. Das führt dann zu 100% CPU load und entsprechend läuft die logic-queue hoch.
Oder es ist gar nicht die CPU load sondern die Anfragen an den mysqld werden nur langsam(er) abgearbeitet und daher staut es sich.