Ich habe die 2 Verbrauchsberechnungen, die überhaupt nicht schnell vorankamen, und beim Betrachten der CPU-Kurven (4 vCPU) lag die Auslastung bei nicht mehr als 10%.
Handelt es sich hier um Single-Thread-Berechnungen oder liege ich völlig falsch?
Der Absturz ist auf dem Diagramm um 22:17 Uhr zu sehen, das Weiß entspricht nicht abgerufenen Informationen, Gladys funktionierte sehr gut.
Bei der Festplatte habe ich Anstiege/Abfälle und seit dem Absturz bin ich sehr hoch geblieben!
Nach der Untersuchung stellt sich heraus, dass mein Proxmox-Skript erkennt, dass der RAM voll ausgelastet ist (5,9 GB/6 GB) während der Migration und dann Docker Gladys neu startet.
Ich werde das deaktivieren.
Aber wie viel RAM wird benötigt, um ein Gerät zu migrieren, ohne dessen Verlauf zu migrieren?
Ich habe das Gefühl, dass es viel Speicher verbraucht.
Ich habe nicht besonders viele (Szene/Dashboard), in denen ich zum Beispiel den Anemometer verwende (das war es, was ich migrieren wollte.
Meine DuckDB ist fast 10GB groß, spielt das eine Rolle?
Jedenfalls migrierte ich gestern das Gerät ohne jegliche Historie und der RAM stieg bis zum Absturz (6GB) an, und dann musste ich manuell neu starten, weil OOM.
Heute habe ich meinen LXC von 6 auf 8GB RAM erhöht, Migration ohne Historie gestartet: super schnell!
Aïe, tatsächlich, wenn deine Datenbank 10 GB groß ist und viele Zustände migriert werden müssen, dann ja, das kann eine ganze Weile dauern und viel RAM verbrauchen.
Hast du die Möglichkeit, temporär mehr RAM zuzuweisen, nur für die Dauer der Migration?
Zu dem Speicher, der sich danach nicht freigibt: Das ist normal und kein Leak. DuckDB behält seine Seiten im Cache bis zu seiner Speichergrenze, und das System gibt ihn nicht sofort frei. Er wird von Gladys wiederverwendet und unter Druck freigegeben.
Und ich empfehle dir, das automatische Neustarten bei RAM-Schwellenwert während solcher Operationen zu deaktivieren: Gladys während einer Migration neu zu starten, lässt die Arbeit halb fertig zurück (es ist wiederholbar, aber man sollte es vermeiden).
already done, aber ich muss auf 10 oder 12 GB gehen, weil ich seit über einer Stunde eine Migration laufen habe und die 8 GB voll sind und Gladys abstürzt, das Dashboard aktualisiert sich nicht mehr
ok, ich werde es dann beobachten, um zu sehen, was mit der Zeit passiert.
Okay, ich gehe jetzt noch einmal Gladys neu starten
Hat jemand das gleiche Problem mit einer Migration gehabt?
@mutmut, bei mir gibt es keine Probleme mit einer fast identischen Konfiguration wie deiner.
Ich habe meinen Netatmo-Thermostat ohne Probleme migriert, ohne Verzögerungen und es war sehr schnell. Meine Datenbank ist 6 GB groß.
Ich habe es geschafft, meinen LXC live auf 12 GB zu erweitern, ohne neu zu starten, und die Migration meiner externen Station (mit allem, was migriert werden muss) hat 1 Stunde und 26 Minuten gedauert, mit erheblichen Verzögerungen bei den Verbrauchsberechnungen während der Migration.
Ich wechsle zur internen Sonde mit allem, was migriert werden muss.
Jedenfalls, für die 4 zu migrierenden Module, eines nach dem anderen, bin ich bei über 24 Stunden
Das Hauptproblem, das ich sehe, ist, dass, solange die Migration nicht abgeschlossen ist, die Verbrauchsberechnung in Wartestellung ist, sowie alle, die danach kommen.
Man müsste die Priorität der Migration verringern, um die Verbrauchsberechnungen durchzuführen und es würde auch ermöglichen, immer die Kontrolle über die Dashboards zu behalten.
Zum Beispiel, die Verbrauchsberechnung hat gerade begonnen, also 2 Aufgaben mit der Migration, und das verlangsamt meine Gladys enorm.
Danke, diese Zahlen sind sehr nützlich, und deine Analyse ist korrekt.
Was teuer ist, ist nicht die Historie des Geräts, das du migrierst, sondern die Gesamtgröße deiner Datenbank: Jede Funktion wird durch eine Abfrage verschoben, die durch Teile durchgeht und diese in der gesamten 10-GB-Datei neu schreibt. Eine externe Station = 4 bis 6 Funktionen = genauso viele vollständige Durchläufe, daher deine 1h26. Deshalb hat @Will_71 auch nichts gesehen: Ein Thermostat hat drei Mal weniger Funktionen auf einer kleineren Datenbank. Und ich warne dich gleich: Der interne Sensor wird der längste der vier sein, das ist das Modul mit den meisten Funktionen.
Zu deinem Vorschlag, die Priorität der Migration zu senken: Du hast recht im Prinzip, aber es gibt keine Priorität, die man einstellen kann: Die Verschiebung ist heute eine einzige große SQL-Abfrage, und solange sie läuft, kann nichts dazwischenkommen. Die richtige Korrektur besteht darin, sie in Scheiben zu zerlegen, wie es die Bereinigung der Zustände bereits tut: Der Speicher bleibt begrenzt, und Gladys übernimmt zwischen jeder Scheibe wieder die Kontrolle für die Verbrauchsberechnungen und die Dashboards. Das werde ich tun, und dabei gibt es eine echte Fortschrittsanzeige (heute bleibst du bei 5 % stecken, während der gesamten Operation, was niemandem hilft).
Dass du auf 12 GB hochgehen musstest, ist nicht normal: Das ist kein Cache, sondern unbegrenzter Transaktionsspeicher. Nach dem Korrekturupdate sollte es ohne zusätzliche Maßnahmen funktionieren.
@spenceur dein Fall beim Löschen hat wahrscheinlich die gleiche Ursache und wird gleichzeitig untersucht.
Danke für deine Maßnahmen, sie haben geholfen, das Problem zu finden, und es ist behoben.
Die Ursache. Das Verschieben des Verlaufs startete eine Abfrage pro Funktion, und jede davon durchsuchte deine gesamte Datenbank. Der tatsächliche Aufwand ist daher nicht proportional zum Verlauf des Geräts, das du migrierst, sondern zum Produkt (Anzahl der Funktionen × Größe der Datenbank). Eine Wetterstation hat 5 oder 6 Funktionen, also 5 oder 6 vollständige Durchläufe über deinen 10 GB: voilà deine 1h26. Das ist auch der Grund, warum Will_71 mit seinem Thermostat nichts gesehen hat, weniger Funktionen auf einer kleineren Datenbank. Und dein Hinweis zur Priorität war richtig: Die Migration belegte die DuckDB-Schreibverbindung von Anfang bis Ende, nichts konnte sich dazwischen schieben.
Was gemacht wurde. Der Verlauf wird jetzt in Abschnitten verschoben, alle Funktionen werden in derselben Abfrage behandelt. Gladys gibt zwischen jedem Abschnitt die Kontrolle zurück, mit einer absichtlichen Pause der Dauer des Abschnitts, damit die Verbrauchsberechnungen und Dashboards weiterlaufen. Der Fortschritt ist real, mit einem Echtzeit-Zähler der verschobenen Zustände, kein festes 5 % mehr. Die Gerätelöschung wurde nebenbei korrigiert, es ist derselbe Mechanismus (das sollte spenceur beantworten).
Die Messungen, auf einer Testdatenbank von 2,9 GB und 176 Millionen Zuständen, für ein Gerät mit 6 Funktionen:
• dauer: 347 s vorher, 18,6 s danach
• Größe der DuckDB-Datei: sie verdoppelte sich während des Vorgangs (2,9 GB wurden zu 5,8 GB), sie wächst jetzt um 6 %
Auf einer 5 Mal kleineren Datenbank war der Gewinn nur ein Faktor von 4,5, hier 18: Je größer die Datenbank ist, desto größer ist der Gewinn, also bei deinen 10 GB sollte es mindestens genauso gut sein. Rechne eher mit einem Faktor von 9 in der Praxis, die absichtliche Pause kostet etwa die Hälfte der Zeit, das ist der Preis, damit Gladys weiterhin verwendbar bleibt.
Meine Bedenken, um ehrlich zu dir zu sein:
Ich konnte deinen RAM-Ausbruch auf 8 GB auf meiner Testdatenbank nicht reproduzieren, der gemessene Speichervorteil ist bescheiden. Was ich sehr klar reproduzieren konnte, ist die Verdopplung der Datei auf der Festplatte, und ich denke, das ist deine echte Ursache: In einem LXC zählt der Festplattencache zum vom Proxmox-Skript gemessenen RAM, also das Schreiben von 3 GB mehr füllt den Speicher, wie er ihn misst. Das passt genau zu deinen Festplattendiagrammen. Aber solange du es nicht bei dir zu Hause erneut getestet hast, bleibt es eine Hypothese.
et nun ja, « nur » 44mn07s aber mit 12GB RAM, bis das vorbei ist.
Super! denn das brachte keine zusätzlichen Informationen.
Ich hatte das tatsächlich, weil mein LXC 20GB Festplatte hatte und ich es schnell auf 30GB erhöhen musste, um nicht mehr durch den von der Datenbank verwendeten Speicherplatz blockiert zu werden.
Was den Cache betrifft, jetzt, wo du es erwähnst, beträgt er 1GB in meinem LXC und jedes Mal, wenn der RAM überlastet war, war der Cache vollständig gefüllt. Ich weiß nicht, ob das davor oder danach war.
Seltsame Sache, als ich temporär auf 12GB ging, stieg der RAM fast bis zum Anschlag und nachdem alle Aufgaben erledigt waren, sank er auf 7-7,2GB, ohne jemals tiefer oder höher zu gehen. Der Cache war immer noch voll, also habe ich mir einen kleinen Reboot und eine Rückkehr auf 8GB erlaubt.
Aktuell liege ich bei etwa 5GB RAM auf den zugewiesenen 8GB, der Swap ist fast leer.
Ich werde versuchen, die Migration mit deinem nächsten Fix an einem Backup, das ich auf einer Testinstanz habe, erneut zu testen, um den Unterschied zu sehen, und ich werde dich hier darüber informieren.
Auf jeden Fall danke für deine Untersuchung und Lösung!
Zur Info, erfolgreiche Tests auf einer Zimaboard und Docker mit 7GB RAM für Gladys und wenig freiem Speicherplatz (1,5GB frei für eine DuckDB von 5,5GB):
Der RAM ist etwas gestiegen, aber ohne an die Grenze zu gehen.
Super Optimierung, großartig @pierre-gilles
Auf meinem Proxmox mit LXC (6GB RAM und eine DB von 5,5GB): ca. 500-700MB Festplattenspeicher während der Migration verwendet, und eine DUCKDB_MEMORY_LIMIT=2000MB in meiner Docker Compose.
