[Featurewunsch] Lastverteilung edomi <-> DB auf Mehrkern-CPU | Datenarchiv-housekeeping

[saegefisch]

Hallo Christian,
vorab: nach vielen Monaten edomi-Pause endlich mal wieder dran. Endlich viele Altlasten in Logik, KO-Struktur und Visu aufgeräumt und für neues bereit gemacht. Vielleicht schaffe ich es sogar mal, meine Visu so weit zu bringen, sie hier zeigen zu können. Nach einer langen Pause fällt es weider auf: Es ist dabei unfassbar, wie geschmeidig und gut edomi funktioniert und zu bedienen ist. Ja, hier und wünscht man sich (auf sehr hohem Niveau) noch dies und das (das Konfigurationsfenster dürfte z.B. größer sein, um weniger scrollen zu müssen), aber offen gesagt: Ich kenne wenig SW, die so einfach und effizient bedient werden kann (z.B. wenn sich Dialoge merken, wo ich beim letzten Aufruf war bei Fleißaufgaben). Und verdamt viel Spaß macht es auch, weil es einem grenzlose kreative Möglichkeiten schenkt - in Visu und Logik. Daher als erstes mal wieder mein Respekt und ein riesen Dank an Dich und Deine brilliante und geniale Leistung mit Deinem edomi!

Eine grundsätzliche Frage hat mir die Zeit aufgeworfen: Mein Archive waren anfangs unreflektiert zu dick, die DB hatte Monat für Monat einiges mehr zu leisten. Ist nun aufgeräumt und anders gelöst (u.a. mit 18000020), aber was mir auffiel:

• Wenn man viel an edomi schraubt, starten man sehr oft neu. Es scheint mir (auch gemäß online-Hilfe zu Datenarchiven), dass die DB jedes Mal schaut, ob Daten aus dem Archiv gelöscht werden können (housekeeping). Bei jedem Start. Wäre es nicht sinnvoll, das housekeeping auf genau einmal pro Tag zu reduzieren? Denn wenn das Archiv dicker wird, dann dauert die Zeit von "grün" bis "edomi ist nutzbar" wenige Sekunden bis hin zu 2 min (bei 20Mio...aus leidiger Erfahrung...). Ich bin wieder runter bei "wenigen Sekunden", doch scheint es mir einfach nicht nötig.
• Ich habe für edomi mir eigens einen NUC-i3 mit 2 Kernen und 4 HT gekauft; war damals das aktuelle Modell und schadet sicher nicht. Nun scheint es mir, dass wenn die DB aufräumt, dann zieht sie 100% eines Kerns. In der Zeit ist edomi nahezu nicht verwendbar (z.B. kann man keine Szenen aufrufen, was meine Familie dann immer merkt). In "htop" sehe ich, dass die anderen 3 Kerne dabei kaum ausgelastet sind:
  • Kann edomi nicht auf einem anderen Kern parallel laufen; dort sollte ja Ressource frei sein? Oder "hängt" edomi, weil es ohne DB überhaupt nichts tun kann und edomi - egal auf welchem Kern - schlicht auf die DB wartet?
  • Könnte man die DB-Aufgaben des housekeeping nicht strecken/verteilen/paketieren, um z.B. nach jeder abgearbeiteten Tabelle edomi mal kurz Zeit zu geben, seine Arbeit zu machen? Derzeit scheinen es für x Tabellen nicht x queued Tasks zu sein, sondern das gesamte housekeeping ist ein einziger Task in der Queue. Und bis das fertig ist, läuft quasi nix.
  • Oder kann man dem housekeeping nur 80% CPU zugestehen und die restlichen 20% der DB sind für das "normale" (non-housekeeping) eodmi-Geschäft bereits parallel nutzbar?
  • Angemerkt sei: Dies ist vermutlich auch ursächlich für gelegentliche mitternächtliche (und bei Neustart) KNX-Problemchen im Log (ACK, Counter,...), weil edomi in der Zeit des housekeeping mir nahezu handlungsunfähig erschient.

In diesen Kern/Threat-Tiefen der IT habe ich nur theroetische Ahnung und keinerlei Erfahrung/Wissen - bitte sieh' mir mögliche Naivität bei den Fragen nach...

Viele Grüße,
Carsten

[saegefisch]

Bin ich tatsächlich der einzige, der trotz Mehrkern-CPU das Problem hat, bei größer werdenden Datenarchiven bei jedem Start nach "grün" ein paar Sekunden bis hin zu 2min (je nach Größe) auf das houeskeeping warten zu müssen, bis edomi trotz "grün" wieder reagiert? Man sieht an der CPU-Last oder in "top"/"htop" (100% ein Kern mit sql) und an der Queue, die in dieser Zeit nie 0 erreicht... Wär' natürlich auch eine Erkenntnis (zum eigenen Konzept, zur Archiv-Stratgie und/oder zur HW)...

[wintermute]

Ich bin kein DBA aber nach meinem (durchaus auch nicht mehr aktuellem) Kenntnisstand, weisst der MySQL Thread-Manager jedem verbundenen Client einen dedizierten Thread zu (der dann nach Moeglichkeit auch noch "recycled" wird).
Damit ist die Frage ja eigentlich auch schon beantwortet

Verbinde dich mit nem zweiten Client, dann wird auch der zweite Kern benutzt

Im Kern (Haha, Wortspiel!) ist das ganze noch etwas komplexer und sowieso: viel der CPU-Zeit spielt sich in I/O Wait States ab und da macht es nun wenig Sinn ob einer oder 8 Kerne darauf warten, dass die Festplatte fertig wird.
Ob das jetzt besser werden wuerde wenn EDOMI mehrere Verbindungen gleichzeitig oeffnet weiss ich nicht - ist IMHO auch eher akademisch. Jedenfalls ist es nach meinem Kenntnisstand nicht moeglich eine einzelne MySQL-Operation auf mehrere Threads aufzuteilen - zumindest nicht unter Linux, unter anderen Un*xen uU schon - das ist jetzt aber schon wieder rein akademisch

EDIT: Und nee, du bist nicht der Einzige. Ich habe den Effekt auch

[saegefisch]

Danke, Michael Okay, das ist für mich schon mal ein Erkenntnisgewinn. Und es fühlt sich auch besser an...

Dann bleibt meine anderen Fragen zu einer Lösung: Kann man es auf 1x pro Tag und nicht bei jedem Start begrenzen (das houeskeeping, nicht eine eventuelle Reparatur) [Featurewunsch] und/oder kann man die aufzuräumenden Archiv-Tabellen (wird ja vermutlich eine Art Schleife sein) nicht nacheinander in einzelnen Threats starten, damit dazwischen edomi schon mal arbeiten kann und/oder vielleicht kann man die Lastobergrenze <100% für diese DB-Operationen setzen. Mit all' dem wäre das beim Neustart deutich unauffälliger...

[gaert]

Naja abgesehen davon, dass so ein Neustart bei mir zumindest äußerst selten stattfindet (vielleicht einmal pro Monat nach diversen Änderungen an der Visu): Machen kann man vieles Allerdings sollte m.E. gerade bei einem Neustart alles auf einen aktuellen und definierten Zustand gebracht werden - erst recht die Datenbanken und deren Inhalte.

Natürlich könnte man z.B. die Archive erst später aufräumen, aber dann trudeln quasi nach und nach die gewünschten Zustände ein. Ist das wirklich so vorteilhaft?

Vielleicht wäre es sinnvoller die Archivstrukturen zu überdenken - muss man wirklich Millionen von uralten Daten in der DB speichern? Beispielsweise Temperaturen: Ich würde die max. 1 Jahr speichern wollen (wenn überhaupt), ggf. würde ich die älteren Werte dann z.B. täglich mitteln und den Rest verwerfen. Eine solche Funktion ist übrigens in Planung, d.h. Archive können dann automatisch "komprimiert" werden, indem Mittelwerte gebildet werden.

[Brick]

eine solche funktion ist übrigens in planung, d.h. Archive können dann automatisch "komprimiert" werden, indem mittelwerte gebildet werden

TOP !!

[saegefisch]

Hi Christian,
das meine bisherigen Myriaden Daten sinnfrei sind, da sind wir uns einig. War halt aus den Anfangstagen 2016 so gewachsen... Habe ja schon geschrieben, dass ich fast alles gelöscht und jetzt mehrstufig aggregiert mit Deinem LBS 18000020 nun gut zurecht komme. Insofern ist eine direkte Aggregationsfunktion sehr fein für die Zukunft, aber der LBS tut jetzt seine Arbeit auch schon gut.

zur Anzahl Neustart: in den letzten Monaten nur, wenn mal der KNX-Bus hakte. Aber wenn man endlich mal wieder aktiv an Logik und Visu arbeitet, dann liegt es wohl in der Natur der Sache, sehr oft neu zu aktivieren und jedes Mal sehe ich nach ca. 50s „gelb“ diese SQL-Last-Starre trotz „grün“. Auch wenn es nun mit aufgeräumten Archiven nur noch Sekunden sind: Das scheint mir Optimierbar und daher meine Vorschläge, weil in dieser Zeit edomi tatsächlich paralysiert ist. Wenn meine Archive sinnvoll aufgebaut sind, rechne ich mit rund 15sek dieser zrit. Aber eben bei jedem neuen aktivieren.

ich kann mit den reduzieren Archiven und nun nur wenigen zusätzlichen Sekunden gut leben, aber wenn Du dort gelegentlich Potential zur Verbesserung siehst, freut es mich, denn sie scheinen mir so oft tatsächlich unnötig, wenn es „nur“ die Prüfung aller Archive ist, ob Sätze wegen ihrer Lebenszeit gelöscht werden können (so steht’s in der Hilfe)..
Sollte mein Eindruck falsch sein und es geht um die Konsistenz der DB, dann habe ich nix gesagt und mein ganzes Thema ist hinfällig...

[mfd]

Aber wenn man endlich mal wieder aktiv an Logik und Visu arbeitet, dann liegt es wohl in der Natur der Sache, sehr oft neu zu aktivieren und jedes Mal sehe ich nach ca. 50s „gelb“ diese SQL-Last-Starre trotz „grün“. Auch wenn es nun mit aufgeräumten Archiven nur noch Sekunden sind: Das scheint mir Optimierbar und daher meine Vorschläge, weil in dieser Zeit edomi tatsächlich paralysiert ist.

Ich kann das genau so bestätigen.
Was ich bei der ganzen Sache etwas schwierig finde, dass der normale Endanwender zunächst mal gar nicht weiß was er (falsch) gemacht hat, dass der Start dermaßen verzögert wird.
Bei mir war es auch so, dass EDOMI anfangs in weniger als 10s vollständig gestartet war. Derzeit dauert es zwischen 30s und 1min. Wenn man den Hintergrund kennt ist es ja weniger schlimm. Störend ist es nur, wenn man an der Visu Veränderungen vornimmt. Dann stören aber auch andere Faktoren wie die vielen Leseanfragen an den Bus und die Logiken die "neu starten" müssen.

Aus meiner naiven Anwendersicht würde ich es am elegantesten empfinden, wenn Visu Änderungen ohne eine vollständige Projektaktivierung einfach übernommen werden könnten. Es ist mir klar, dass das mit dem Grundkonzept derzeit vielleicht nicht vereinbar ist (Arbeitsprojekt - Liveprojekt usw.) es würde die Arbeit an einer Visualisierung aber auf ein neues Level bringen.
Die eingebaute Vorschau ist zwar eine Hilfe, aber gerade bei kniffligeren Dingen wie Seitenaufrufen, wertabhängigen Positionen von Elementen oder Einstellung von Haltezeiten nicht nutzbar.
Es gibt einfach nichts besseres als direkt sehen zu können, ob das gerade neu eingebaute auch wunschgemäß funktioniert...

[gaert]

Uff Liste steht schon länger sowas wie "Schnellaktivierung für Visu" Das Problem ist aber, dass die Visu u.U. zahlreiche Abhängigkeiten aufweist (Logiken, KOs, etc.), deren Änderungen nicht mal eben schnell aktiviert werden können. Eine derartige Schnellaktivierung wäre also eher eine erweiterte Vorschau...

Kommt Zeit kommt Rat Ich widme mich bevorzugt erstmal Dingen, die den Funktionsumfang sinnvoll erweitern - Komfort rückt stets nach hinten

[mfd]

Uff Liste steht schon länger sowas wie "Schnellaktivierung für Visu" Das Problem ist aber, dass die Visu u.U. zahlreiche Abhängigkeiten aufweist (Logiken, KOs, etc.), deren Änderungen nicht mal eben schnell aktiviert werden können.

Verständlich, dass das nicht mal so eben machbar ist, sonst würde es das vermutlich ja schon geben. Ich wollte hier nur meine Gedanken aus Nutzer-Sicht aufzeigen. Diejenigen, die ohnehin ein paar EDOMI-VMs nebenbei zum Ausprobieren laufen haben, wird das wenig stören.

Der "normale" Endanwender mit ein paar Logiken und einer Visu für's EFH wäre aber sicher froh über eine solche Möglichkeit. Schließlich ist gerade beim Einstieg viel Ausprobieren und immer wieder Nachbessern der erstellten Visuelemente an der Tagesordnung.
Deshalb wäre es für mein Empfinden mehr als nur ein Komfortgewinn.