UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Marty56]

@paul53 @paul53 Ist schon klar, dass eine Stunde lang ist. Auf der anderen Seite sind meine Zuverlässigkeitsanforderung an meine Homeautomation auch nicht extrem und die Stabilität war bisher tadellos.

Kann ich eigentlich die SQLlite3 DB in Redis ablegen?
Vermutlich eine blöde Frage.

[Marty56]

@bbtown keine Ahnung. Ich hatte nach 16 Tagen 5 TByte geschrieben. Das erschien mir schon relativ viel

[apollon77]

@marty56 naja eine Datenbank schreibt Daten die gespeichert werden sollen. Wenn primär Daten dazu kommen sollte es an sich fast egal sein ob alles einmal pro Stunde oder direkt geschrieben wird. Bei SQLite wär ich mir da nicht gaaaanz so sicher ob das equivalent ist aber so weit auseinander sollte es auch wider nicht sein.

Datenbanken haben von Natur aus die Anforderung keine Daten zu verlieren ;-) also ob Du eine dB findest die das „bricht“ weiß ich nicht ;-)

[Dr. Bakterius]

@apollon77 Hat sich denn im controller etwas geändert? Ich habe ja schon seit Monaten 'jsonl' in Betrieb und die geschriebene Datenmenge war seitdem erfreulich gering. Doch seit Ende Juli als die ganzen Updates aufschlugen habe ich wieder eine extreme Schreiblast laut Proxmox (etwa hundertfach!). Laut htop ist es der Prozess iobroker.js-controller. Mit deutlichem Abstand folgt io.backitup.0. Ich habe mal alle Instanzen gruppenweise deaktiviert. Da hat sich nichts geändert. Erst wenn iobroker gestoppt wird, fallen die Schreibzugriffe wieder auf faktisch Null.

[apollon77]

@dr-bakterius Geändert hat sich nichts. Der controller 3.3 hat ne neue Version der jsonl mitgebracht und wenn Du immer noch jsonl nutzt dann sollte das auch weiterhin so sein. AUch bei jsonl hat sich nicht wirklich was geändert.

Also checke mal "iobroker setup custom" zuerst. ansonsten muss irgendein adapter "schuld" sein. Den müsstest Du dann finden denke ich

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Also checke mal "iobroker setup custom"

Current configuration:
- Objects database:
  - Type: jsonl
  - Host/Unix Socket: 127.0.0.1
  - Port: 9001
- States database:
  - Type: jsonl
  - Host/Unix Socket: 127.0.0.1
  - Port: 9000
- Data Directory: ../../iobroker-data/

Sieht soweit okay aus. Und wie gesagt, ich habe alle Instanzen gestoppt und trotzdem kommt es etwa alle drei Minuten zu einem hohen Diskwrite.

'htop' zeigt:

Und unter Proxmox sieht man den gewaltigen Anstieg:

Weiß echt nicht was ich noch prüfen könnte...

[FredF]

@dr-bakterius seitdem jsonl angeboten wird, habe ich ioBroker umgestellt, habe die Diskwrites aber nicht weiter beobachtet.. Controller update habe ich auch schon eine Zeit lang gemacht.
So schaut es derzeit aus:

iobroker setup custom:

Current configuration:
- Objects database:
  - Type: jsonl
  - Host/Unix Socket: 0.0.0.0
  - Port: 9001
- States database:
  - Type: jsonl
  - Host/Unix Socket: 0.0.0.0
  - Port: 9000
- Data Directory: ../../iobroker-data/

Was ich am 17.8. um 20 Uhr gemacht habe, das die Werte seit dem wieder höher sind muss ich mal recherchieren...

Edit: hmm nichts spannendes passiert, außer das wie vorher auch so ein paar Adapter abfragen starten..

[Kueppert]

@fredf sagte in ioBroker sehr hohe Diskwrites in Proxmox:

iobroker setup custom

hab auch mal gerade geschaut, hab auch jsonl bei beidem drin seit langem. Disk io sieht bei mir unauffällig aus:

PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...

[FredF]

@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:

PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...

Einfach alles mit Enter bestätigen

Edit: Bzw. mit Strg + c abbrechen

[Kueppert]

@fredf war in der Proxmox Konsole, da geht kein STRG + C. Hab einfach alles bestätigt :fist:

[Dr. Bakterius]

@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Disk io sieht bei mir unauffällig aus

Also ich war vor dem Anstieg noch wesentlich weiter unten als du - jetzt habe ich mehr als das doppelte von dir.

Und wie gesagt, alle drei Minuten der Zugriff:

Wird jetzt sicher nicht gleich meine SSD schrotten, aber interessieren würde mich doch was das ist...

[apollon77]

Dann wiederhole ich was ich oben geschrieben habe: da müsste ein Adapter „schuld“ sein. Finde raus welcher.

Alternativ schau was die jsonl files in iobroker-data machen. Sie müssten ja dann zu dem genannten Zeitpunkt neu komprimiert werden - ergo kleiner werden. Dann schau welches file es ist.

[Dr. Bakterius]

@apollon77 Ich habe jetzt über eine Stunde gesucht. Alle Instanzen beendet und dann der Reihe nach gestartet. Irgendwann sind die Schreibzugriffe angestiegen und häufiger geworden. Einen speziellen Adapter konnte ich dabei nicht ausmachen.

Die 'states.jsonl' steigt laufend in der Größe an, und wird wenn sie ungefähr die doppelte Größe erreicht hat neu geschrieben. Ich steh an... :confused:

[apollon77]

@dr-bakterius Ok, also states.jsonl ... und passt das zu "alle 3 Minuten"? Dann hast DU einfach viele state updates ...

[Dr. Bakterius]

@apollon77 Ja, und doch frage ich mich warum das plötzlich so ist. Gäbe es eine Möglichkeit darzustellen wie oft und bei wie vielen Datenpunkten welcher Adapter aktualisiert (in Admin oder Info)?

[Marty56]

Bei mir läuft in 2-3 Wochen der Swap Speicher voll. Ganz langsam.

Promox PVE Webui öffnet sich dann immer langsamer und am Schluss muss ich die iobroker LVC neu starten.

Es hängt bei mir am History Adapter. Ähnliches Verhalten habe ich auch aber noch schneller beim SQL Adapter beobachtet.

Ich benutze json.l

[apollon77]

@dr-bakterius Also im Admin kann man an sich pro Adapter sehen wieviele Änderungen (States/Objects zusammen) gemacht werden ... müsste man im Expertenmodus in der Instanzansicht sehen

[apollon77]

@marty56 Ok laaaaangsam!!

Swap "läuft" nicht zu ... Swap wird genutzt wenn es nötig ist. Wenn das System Swap nutzt dann heisst das erstmal das es zeitpunkte gab wo der verfügbare RAM nicht gereicht hat und mehr gebraucht wurde und damit wurden Daten aus dem RAM ins Swap ausgelagert. AN sich nichts schlimmes, aber wenn es so ist wie Du beschreibst dann würde ich der VM/LXC mal mehr RAM geben und das Problem ist gelöst.

An sich mit "free -m" prüfen wie es der RAM Nutzung geht und ggf mit "top" schauen welcher Adapter es ist.
Bei History und SQL kann das daran liegen wenn oft Charts genutzt werden, dann muss der halt immer Daten im RAM haben (und je länger die Zeiträume sind desdo mehr).

Das gehört hier aber nicht hin

[Dr. Bakterius]

@apollon77 Meinst du die Ereignisse?

Die wirken sich merklich auf den Netzwerk-Traffic aus nicht auf den Disk-IO. Zumindest als ich die beiden Instanzen mit den meisten Ereignissen (hue und javascript) deaktiviert hatte, ging der Netzwerk-Traffic auf etwa die Hälfte zurück, doch die states.jsonl ist fast genauso schnell angewachsen wie zuvor.

Mittlerweile habe ich mehrfach alle Instanzen einzeln gestoppt und beobachtet - es ist an keinem Adapter festzumachen!

[apollon77]

@dr-bakterius interessant ist der zweite wert. Das sind „state changes“. der erste ist nur das was der Adapter von anderen subscribed hat. Und ja Admin bekommt halt am Ende viele Daten aber schreibt selbst wenig.

Du musst die suchen die alle zweite Zahl viel haben.