Projektaktivierung dauert lange

[ricvanholly]

Danke für den Thread, Leute. Habe bei mir seit Wochen ähnliche Symptome gehabt und den simpelsten Grund nicht bedacht 😯. Meine VM hatte nur 2 Gig Speicher -> nach der Erweiterung der Platte läuft's wieder rund 👍👍

[rdeckard]

Also ich habe knapp 15 Mio. Einträge in der Archiv-Tabelle (ca. 500 MB Daten und ca. 515 MB Index)....

Huch...170 Mio. Einträge in Edomi (MySQL) ist glaub schon eine Hausnummer.

[Ing-Dom]

170 Mio Einträge
Edomi ist virtualisiert in der VirtualBox, Host ist ein Intel G4400(2x3.3GHz) System mit 16GB Ram und eigene 100GB SSD für edomi

Die meisten Einträge kommen durch das hochfrequente Tracken meiner PV- und Stromzählerdaten. (5s / 1s)

[jonofe]

Wie viele Elemente habt ihr denn eigentlich so im Archiv.
Bei mir sinds ca. 5 Mio und die DB ist inkl. Index ca. 400 MB.
Wenn ich das mal linear auf 7-8 GB Archiv-DB hochrechne, dann ....

... hoffe ich, dass es Futro 920 ist, auf dem das läuft ...

[Ing-Dom]

hm. Die Zeit bis "Verbindung herstellen zur Datenbank" mag es verkürzen (bin nicht sicher) aber die Zeit in der edomi grundsätzlich läuft aber mit 100% CPU-Last und nix geht so richtig, die bleibt gleich.
In der Zeit ist der mysqld im "top" immer wieder ganz oben mit dabei (abwechselnd mit system).

[jonofe]

Wäre nur interessant welcher?

Es ist vermutlich dieser Zusammenhang:

DB.PNG

Hier sollte es aus meiner Sicht eine weitere Option geben "nach Reboot" geben.
Nach dem Ausschalten ist der Start bei mir um den Faktor 4-5 schneller.
Bei wirklich großen Datenarchiven ist dieser Faktor evtl. noch höher, da bei mir die meiste Zeit für den KNX Initscan verwendet wird.

[saegefisch]

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

Bin noch am umziehen von 1.64 auf 2.02. Wenn ich an am influxDB-Teil ankomme, schreibe ich hier gerne ein paar Zeilen dazu.

[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.

[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]

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?

[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

[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.

[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]

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.

[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.