Leistungsproblem im Dashboard mit vielen Grafiken

[pierre-gilles]

Hallo @lmilcent!

Abgesehen davon, direkt in die Datenbank zu greifen, habe ich keinen besonderen Tipp Nimmt das wirklich zu viel Zeit auf deinem Pi in Anspruch?

Du kannst ein Programm wie TablePlus auf deinem PC verwenden, um eine saubere Schnittstelle für deine Datenbank zu haben.

Denke daran, Gladys zu stoppen, bevor du deine neue Datenbank abrufst/erneut einspielst.

[lmilcent]

@pierre-gilles

Denke daran, Gladys vor dem Abrufen/Einfügen deiner neuen DB zu stoppen

Ja, ich habe festgestellt, dass die Datenbank sonst beschädigt wird.

@pierre-gilles

Abgesehen vom direkten Zugriff auf die DB habe ich keinen besonderen Tipp Braucht das wirklich so lange auf deinem Pi?

Ja, ich bestätige dir, dass es seit über 12 Stunden läuft, für die Löschung einer einzigen Funktion. Aber ich weiß, dass das mit zwei Dingen zusammenhängt: einer 8-GB-Datenbank und einem RPi mit einer SD-Karte und keinem SSD.

Falls du es zur Hand hast, kannst du mir bitte sagen, wie ich:

1. Features nach Geräten auflisten
2. Daten einer Funktion löschen (und ich würde anschließend deren Speicherung in der Oberfläche deaktivieren)

Ansonsten werde ich im Quellcode suchen

Danke

[pierre-gilles]

Hier ist es:

Hilfe! Problem mit der Aggregation?

@lmilcent Hop c’est cadeau: SELECT COUNT(t_device_feature_state.id), device_feature_id, t_device_feature.name as feature_name, t_device.name as device_name FROM t_device_feature_state JOIN t_device_feature ON t_device_feature.id = device_feature_id JOIN t_device ON t_device.id = t_device_feature.device_id GROUP BY device_feature_id ORDER BY COUNT(t_device_feature_state.id) DESC;

Danach, um die Zustände einer Funktion zu löschen:

DELETE FROM t_device_feature_state WHERE device_feature_id = 'cca3209-8d8f-4965-b658-bdb28eb31300';
DELETE FROM t_device_feature_state_aggregate WHERE device_feature_id = 'cca3209-8d8f-4965-b658-bdb28eb31300';

Am Ende nicht vergessen:

VACUUM;

[lmilcent]

Danke, ich wusste, dass du die Arbeit für mich schon mindestens einmal erledigt hast​
Entschuldige die doppelte Anfrage, und nochmals danke!!

[lmilcent]

Ergebnisse in Bildern: Eine um 50% reduzierte Größe

Meine Datenbank ist jetzt 3,8 GB groß, zuvor waren es über 8 GB!

Bei den Backups (persönlich) merkt man das:

[Checconio]

Das ist super, ich habe auch meine Datenbank um 1,6 GB reduziert und es ist toll, dass die Dashboards sofort geladen werden!

[pierre-gilles]

Das freut mich zu lesen

[VonOx]

Man könnte auch die Standorttabelle bereinigen, wir haben die gesamte Standorthistorie, aber die bringt doch nichts, oder?

[pierre-gilles]

In Gladys 3 gab es eine Funktion, mit der man den Verlauf der Bewegungen sehen konnte, das fand ich praktisch

Ist diese Tabelle bei dir wirklich so groß?

[VonOx]

Ich hatte es vor einigen Wochen sauber, ich habe es heute Morgen gemacht (ca. 60.000 Zeilen).

Ich sehe keinen Anwendungsfall für den Standortverlauf.

[pierre-gilles]

Ok, 60.000 Zeilen sind doch nichts Wir können später eine Aufgabe einrichten, um den Verlauf zu leeren (ein bisschen wie bei den States: letzte 6 Monate, letztes Jahr, etc.)

[Will_71]

Super, die Datenbank wurde auch bei mir reduziert und das merkt man bei der Anzeige der Diagramme.

Allerdings habe ich jetzt ein Problem bei jeder Änderung eines Geräts, zum Beispiel seines Namens, wodurch Gladys für mehrere Minuten blockiert wird. (einfach 10 bis 15 Minuten)

Ist das normal?

Ich könnte mehr Details geben und Tests durchführen, aber abends, falls nötig.

[Will_71]

Ich habe also einen Versuch unternommen, um eine Funktion zu einem MQTT-Gerät hinzuzufügen.

Ich musste etwa 22 Minuten warten, bis die Seite nach dem Speichern angezeigt wurde

[Checconio]

Ich bestätige, dass ich denselben Fehler habe.
Wenn ich meine MQTT-Geräte ändere, dauert es jedes Mal sehr lange, bis eine Fehlermeldung angezeigt wird.

Ich muss die Gladys-Instanz neu starten, damit es wieder funktioniert, aber die Änderung wird übernommen.

[Tlse-vins]

Ich bin auf das gleiche Problem gestoßen, als ich die Gerätehistorie gelöscht habe.

Ich hatte keine Zeit, die Information weiterzugeben.

[lmilcent]

Gleiches Problem bei mir.

@pierre-gilles ich weiß nicht, ob das der Fall ist, aber es sieht wirklich so aus, als ob entweder die Datenbank oder Gladys in diesem Moment im Blockiermodus ist.
Denn wirklich nichts reagiert mehr. Also entweder liege ich total falsch (das wäre nicht das erste Mal ), oder es gibt etwas zu tun, um diesen Teil etwas zu optimieren.

Auf meiner Seite sehe ich einen Prozess node index.js bei 100% der CPU, während das Schreiben auf die SD-Karte meines Raspberry Pi nicht bei 100% der I/O zu sein scheint.

[pierre-gilles]

Hallo zusammen!

Wenn ihr ein Gerät registriert, macht Gladys zwei Dinge:

• Wenn bestimmte Features im Historienmodus deaktiviert sind, löscht Gladys alle Zustände dieser Features. Das kann potenziell Millionen von Zeilen in einigen Datenbanken bedeuten, was die DB während der Löschung für eine Weile blockieren kann.
• Danach führt Gladys einen VACUUM aus, einen Vorgang, der die Daten « wirklich » vom Datenträger löscht und Speicherplatz freigibt. VACUUM ist ein blockierender Vorgang, und während des gesamten VACUUM ist die DB, und damit Gladys, nicht zugänglich. Bei kleinen DBs ist das nicht sichtbar, bei großen DBs kann es 20 Minuten dauern und man hat den Eindruck, dass es « kaputt » ist, obwohl es nur arbeitet!

Die Lösung, die ich sehe:

• Eine Hintergrundaufgabe zum Löschen von Zuständen programmieren, die in kleinen Batches löscht, damit Gladys nicht blockiert wird, wenn Features mit Millionen von Zuständen gelöscht werden. Es müssen Tests durchgeführt und die richtige Zahl gefunden werden, damit es weder zu blockierend noch zu langsam ist.
• Den sofortigen VACUUM entfernen und eine geplante nächtliche VACUUM-Aufgabe einrichten, die aktiviert/deaktiviert werden kann (z. B. alle zwei Wochen).

Der Nachteil all dessen ist, dass die « Speicherplatzfreigabe » nicht mehr sofort erfolgt. Nach einer Zustandslöschung muss man bis zur nächsten Nacht oder bis zu einer Woche warten, bis Gladys sich selbst löscht. Eventuell kann man irgendwo einen Knopf einrichten, um manuell zu löschen, aber der Benutzer muss sich bewusst sein, dass Gladys während der gesamten Löschzeit nicht verfügbar ist.

Ich habe aber eine ziemlich volle Woche, also denke ich nicht, dass ich in den nächsten Tagen einen Blick darauf werfen kann. Ich werde es entweder am Wochenende oder im Laufe der nächsten Woche tun! Ich halte euch auf dem Laufenden

[Checconio]

Kein Problem!

Ich denke nicht, dass es dringend ist, da nichts kaputt ist und es nur passiert, wenn man den Verlauf löscht

[Will_71]

Danke für die Analyse!

Aber 20 Minuten für eine kleine Namensänderung zum Beispiel ist sehr lang. Das ist sehr blockierend, sogar etwas ärgerlich, auch wenn wir wissen, dass Gladys nicht kaputt ist und im Hintergrund arbeitet.

Meiner Meinung nach kann die Reinigung später erfolgen, wie du vorschlägst. Und vom Benutzer aktivierbar/deaktivierbar wäre gut.

[lmilcent]

Danke für die Details, jetzt verstehe ich besser, warum wir alle das Gefühl haben, dass es blockiert.
Ich bin für die Lösung mit dem VACUUM nachts (z. B. zwischen 2 und 4 Uhr morgens).
Welcher Nutzer wird sich wirklich um die Größe seiner DB kümmern, wenn es nur ein paar Stunden später ist?