docker stats liefert mir Informationen, die natürlich zwischen ruhigen und intensiveren Momenten variieren (es sieht aus wie ein Zyklus von etwa 10 Sekunden):
oder
oder
et htop:
oder
Ich verstehe besser, mit 1,8 GB RAM auf deinem Pi, wenn normalerweise 600 MB belegt sind, und wenn du im aktuellen Zustand mehr als 1 GB für die Aggregation benötigst (du hast wahrscheinlich Rückstand), dann ist das ein Problem.
Die Aggregation funktioniert Sensor für Sensor, du hast sicherlich einen einzelnen Sensor, der für den hohen RAM-Verbrauch verantwortlich ist, den wir sehen. Eine Analyse der SQLite-Datenbank könnte helfen, herauszufinden, welcher Sensor gemeint ist. Vielleicht nutzt du die Daten dieses Sensors überhaupt nicht und könntest sie löschen ^^ (stell dir vor, es ist so etwas wie der Batterieverlauf der letzten zwei Jahre, den kann man getrost ignorieren). Wenn du deine Datenbank extrahieren kannst, kann ich die Abfragen durchführen und dir sagen, welcher Sensor das Problem verursacht. Andernfalls kannst du die Abfragen auch selbst durchführen, wenn du das kannst 
Falls dir das zu kompliziert erscheint, kannst du zunächst jeden Gerät in der Gladys-Zigbee2mqtt-Integration überprüfen und sicherstellen, dass du nur die Zustände behältst, die du benötigst. Wenn du eine Funktion deaktivierst, löscht Gladys automatisch die historischen Zustände.
Okay, danke für die Analyse. Und das zwingt mich dazu, etwas zu tun, was ich schon länger aufschiebe: die Konfiguration jedes Zigbee-Geräts und jedes MQTT-Geräts zu überprüfen, um möglichst viel historischen Daten zu löschen. Das werde ich erstmal in Ruhe erledigen.
Und dann werde ich auch den Umstieg auf den Mini-PC untersuchen, dessen Vorzüge du regelmäßig lobst 
Der Mini-PC, ehrlich gesagt, lohnt sich…dann kannst du aber auch gute Schnäppchen auf Kleinanzeigen finden und ein Raspberry Pi 4 lässt sich immer noch ganz gut verkaufen.
@pierre-gilles Der Fehler „SyntaxError: Value expected (char 1)“ tritt aufgrund einer Szene auf, die diesen Block „Nur fortfahren, wenn“ enthielt:
Danke für den Hinweis, hier fehlt eine Validierung für diese Szenenaktion! Kannst du ein Github-Issue im Gladys-Repo erstellen, damit wir eine Spur behalten?
Kurzer Rückblick auf meine Reinigung:
- GladysPlus-Sicherung von 5,2 GB vor der Reinigung
- Überprüfung meiner 56 Zigbee-Geräte. Bei den meisten hatte ich die Standardkonfiguration belassen, die alle Indikatoren historisiert
- Insgesamt bin ich von 270 historisierten Indikatoren auf nur noch 80 gesunken, also -70%
- Über die Schnittstelle Gladys>Einstellungen>System habe ich eine Datenbankbereinigung durchgeführt (das hat auf meinem rPi einige Stunden gedauert…)
- Nächste GladysPlus-Sicherung: 2,9 GB
@pierre-gilles Ich frage mich, ob es eine gute Idee ist, dass standardmäßig alle Indikatoren eines neu installierten Zigbee-Geräts historisiert werden… Vielleicht wäre das Gegenteil besser, nichts standardmäßig zu historisieren. Oder einen zusätzlichen Schritt hinzufügen, wenn man die Hinzufügung eines Zigbee-Geräts von der Seite ‹ Zigbee-Entdeckung › bestätigt, um für jeden Indikator eine Wahl zu treffen?
Ich bin also vom rPi auf einen Mini-PC (mit 8 GB RAM) umgestiegen. Und keine Aggregationsprobleme mehr
Mal sehen, sobald wir zu DuckDB gewechselt sind, haben wir nicht mehr dieselben Speicherprobleme, also wird die aktuelle Lösung die einfachste sein.
Fantastisch!
Hallo,
Hier mein persönlicher Erfahrungsbericht zu meinen PIR-Sensoren, die standardmäßig die gesamte Bewegungsgeschichte der letzten 6 Monate gespeichert hatten … (Ich habe derzeit 6 PIR-Sensoren, in den Haupträumen, die potenziell alle 10 Sekunden Bewegungen erzeugen …).
Vielleicht sollten die Sensoren standardmäßig nur für bestimmte Typen (Temperatur, Luftfeuchtigkeit …) historisiert werden?
Schönen Tag noch,
Jean
Das könnte eine Option sein, aber ich denke, wir werden sehen, wie sich das mit DuckDB verhält, denn diese Art von Daten wird wirklich nicht mehr viel Platz beanspruchen (die 0/1 werden von DuckDB extrem komprimiert).
Vor allem, weil wir bald auch die historische Anzeige der Bewegungssensoren auf dem Dashboard haben werden, wird es praktisch sein, diese Daten zu haben