wichtiges UPDATE für controller 7.2.2 im stable

[AlCalzone]

@dr-bakterius Die Datei ist erstmal append-only bis zum erneuten Schreiben nach Erreichen einer Schwelle. Jede Änderung eines States entspricht einer neuen Zeile, die angefügt wird. Wenn durch dieses Anfügen die Datei auf die doppelte Länge des letzten Kompressionsvorgangs angewachsen ist, wird ein neuer ausgelöst. Je mehr States du hast, desto länger dauert es, bis sich die Größe verdoppelt hat, weil die Baseline auch höher ist.

Wie viele States hast du denn insgesamt?

Und bist du ganz sicher, dass es an states.jsonl liegt und nicht objects.jsonl? Nicht dass einer der Adapter seit dem Update ständig seine Objekte neu schreibt. Da ist die Schwelle deutlich geringer und die Datenmenge wesentlich höher.

[Dr. Bakterius]

@alcalzone Ich habe jetzt mal zum Testen wieder auf file|file umgestellt. Da wurden 11.836 states und 10.960 objects konvertiert. Danach den Container neu gestartet und 10 Minuten beobachtet. In diesen 10 Minuten wurden deutlich weniger Schreibzugriffe lt. Proxmox durchgeführt.

Dann wieder zurück auf jsonl|jsonl und ich bin wieder da wo ich vorher war.

In den letzten 15 Minuten wurde die states.jsonl 5x neu geschrieben weil sich die Größe verdoppelt hatte. Die objects.jsonl ist anfangs um 15% angewachsen und bleibt seit 10 Minuten stabil auf ihrer Größe. Ich glaube also nicht, dass ein Adapter ständig seine Objekte neu schreibt.

Anfang des Jahres waren die Schreibzugriffe exorbitant höher als ich noch auf file|file war. Bei redis gingen diese deutlich zurück und dann mit jsonl sanken sie faktisch auf null. Und seit ende Juli sind sie plötzlich so hoch - höher als bei file! Ich verstehe es nicht...

[Kueppert]

Hmmm, ich meine mich zu erinnern, dass ich damals bei der Umstellung auf JSONL irgendwas in einer Datei angepasst hab dafür...aber das wars auch schon, woran ich mich meine zu erinnern...man konnte doch das Verhalten bei JSONL selber etwas manipulieren/seinen Bedürfnissen anpassen? Ggf wurde da was überschrieben?

[apollon77]

@dr-bakterius Naja Du hast zwei Adapter die recht viel ausgehende States hatten ... ggf hat sich ja da was geändert ... bzw @AlCalzone hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt? ;-)

[AlCalzone]

@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:

11.836 states

Lass mal rechnen.
1000 Ausgabeereignisse alle 15 Sekunden, macht etwa 12.000 Schreibvorgänge in 3 Minuten.
Das deckt sich ziemlich genau mit deiner Beobachtung, dass alle 3 Minuten komprimiert wird, weil sich dann die DB-Größe verdoppelt hat.

@apollon77

hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt?

Möglich. Ich weiß nicht genau, welche Version @Dr-Bakterius vorher im Einsatz hatte.

Anyways - hier kann man sicher noch Feintuning betreiben, genau dafür machen wir solche Tests ja. An sich ist die Auto-Kompression dafür gedacht, dass die Dateien größentechnisch nicht komplett aus dem Ruder laufen und das Laden etwas schneller geht.

Für Objects haben wir Größenfaktor 2, mind. 1000 Zeilen als Bedingung für Neu-Schreiben. Die 1000 sind hier die Anzahl der teils redundanten Zeilen in der DB, nicht die einzigartigen Objekte.
Für States ist die Einstellung aktuell identisch. Ich hab nur etwa halb so viele States und meine states.jsonl dümpelt irgendwo zwischen 2-3 MB herum. Also Größentechnisch nix wildes.

Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)

Das wird dafür sorgen, dass die DBs deutlich seltener komprimiert werden - bei kleineren Installationen so gut wie nie. Ist jetzt vermutlich nicht schlimm, aber ggf. muss man es dann zeitgesteuert ab und an machen.

[apollon77]

@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)

Macht sinn und ja States Faktor 10

@Dr-Bakterius machst du uns bitte im js-controller ein issue dazu?

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

machst du uns bitte im js-controller ein issue dazu?

Erledigt. (https://github.com/ioBroker/ioBroker.js-controller/issues/1437)

[apollon77]

@apollon77 @AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?

[amg_666]

@apollon77 Hallo, das ist jetzt vlt etwas off-topic aber ich lese diesen thread mit und bei deiner Antwort zu den "state changes" bin ich etwas stutzig geworden.
Mein System (proxmox container mit debian 10) läuft stabil aber ich habe beim Sonoff Adapter sehr hohe Werte:

Muss ich mir da Sorgen machen oder ist das eben so, wenn man viele (ca 70) Geräte an dem Adapter hat. die auch viele Status-Updates senden?

[AlCalzone]

@apollon77 Öhhhm, geht das? 😅

[apollon77]

@amg_666 naja hast dir die Frage an sich selbst beantwortet. Wenn es viele state changes gibt dann willst du das ja haben also …. Viel state changes der Geräte die beim Adapter ankommen ergeben (logischerweise) auch die gleiche Anzahl States changes in iobroker. ;-))

Am Ende ist das doch auch nicht schlimm und genau das was du willst.

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@AlCalzone vllt willst Du hier sagen wie man das jetzt schon in der iobroker.json konfigurieren kann?

Wäre genau meine nächste Frage gewesen. ;-)

[apollon77]

@dr-bakterius kk haben geschaut… geht nicht so easy

[alexmi]

Hallo Zusammen,

vorab erstmal vielen Dank für diese ganzen Infos die man hier im Forum findet.

Im Bezug auf das Thema Diskwrites habe ich folgendes Problem:

Ich habe den ioBroker erstmal auf *.jsonl laufen lassen.
Dabei habe ich festgestellt, dass mehr als 30GB pro Tag auf die SSD geschrieben wurden.
Ich habe dann testweise man auf Redis umgestellt und habe jetzt 1GB/h also 24GB pro Tag.
Das finde ich einfach zu viel. Es laufen nur 20 Adapter. Ich kann einfach nicht nachvollziehen wieso so viele Daten geschrieben werden.

Vielleicht kann mir jemand helfen? Wenn ja, sagt mir bitte, welche Infos ihr von meinem System benötigt.

Vielen Dank

[apollon77]

@alexmi hm … naja was ist deine Erwartung wenn es mal einen Crash gibt? Ist Datenverlust ok oder nicht? Wie lang das set Datenverlust sein?

20 Adapter ist ohne Angabe welche das sind mit wie vielen Objekten und Anzahl an state changes pro Zeiteinheit auch eine schlechte messgrundlage.

Am Ende ist jsonl auf eine Balance zwischen Schreibaktionen und Datenverlust-Zeit optimiert welche für die Erwartungen der User unserer Erfahrung nach kompatibel ist. Am Ende lassen sich hier settings ändern damit es zu deinen Vorstellungen passt.

Bei redis sind die standard persistenz settings recht suboptimal und sollten nach deinen Vorstellungen angepasst werden. Muss man sich mit den persistentoptionen beschäftigen und sinnvoll customized einstellen. Es gibt einen redis thread hier im Forum von mir wo zu redis einiges beschrieben ist. Hast du den gelesen?

Am Ende hast du ein Smart Home System welches die Haupt Aufgabe hat Daten zu verarbeiten. Ich finde das 24-30gb am Tag nicht viel mit der Sicherheit das ich auch bei einem Crash idealerweise keine bzw. wenige Daten verliere. Sonst gehen nämlich ggf bei einem restart logiken nicht mehr korrekt bis ein wert aktualisiert wurde. Alles eine Frage der Balance …

Was ist denn deine Erwartung und Vorstellung?

Ingo

[alexmi]

Vielen Dank für deine schnelle Antwort Ingo

Das was bei mir an Datenverlust entstehen kann, ist für mich in Ordnung. Ich mache täglich ein ioBroker und Redis Backup mit dem Backitup Adapter und habe auch schon ein Backup wieder einspielen müssen, da ich Probleme mit VIS hatte, dass nichts mehr geladen wurde.

Ja, ich habe den Redis Beitrag komplett gelesen und mich daraufhin auch erst dort ran getraut. Hat alles problemlos funktioniert.
Hab mich mit den persistenoptionen auch auseinandergesetzt.
Die CPU Last hat sich mit Redis auf jeden Fall verringert und daher auch die Betriebstemperatur.
Ein zurück auf jsonl ist ja wieder jederzeit möglich.

Ich habe mit den Datenmengen bisher keine Erfahrungen, mir kam es nur sehr viel vor für das "bisschen" was bei mir läuft.
Aber ich bin jetzt erstmal etwas beruhigter, wenn du sagst, dass die Datenmenge in Ordnung ist.

Hier kann man mal erkennen, was ich für Adapter installiert habe.

Objekte: 4858, Zustände: 4170

CPU: 0,13 %
RAM: 81,1 %
Betriebszeit: 4d3h
Verfügbar: 4.0.23
Installiert: 4.0.23
Ereignisse: ⇥18 / ↦13
Plattform: linux
Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 800 MHz
Modell: ARMv7 Processor rev 3 (v7l)
RAM: 7.2 GB
System-Betriebszeit: 4 T. 00:56:47
Node.js: v16.17.0
time: 1662391338722
timeOffset: -120
Adapter-Anzahl: 510
NPM: 8.18.0
Datenträgergröße: 439.8 GB
Freier Festplattenspeicher: 422.4 GB
Betriebszeit: 4 T. 00:56:51
Aktive Instanzen: 17
Pfad: /opt/iobroker/

Alex

[Thomas Braun]

@alexmi sagte in ioBroker sehr hohe Diskwrites in Proxmox:

NPM: 8.18.0

Die Version ist aber auch nicht die von nodejs 16.17.0.
Da haste mal von Hand dran rumgefummelt.

[alexmi]

@thomas-braun Ja das kann sein, bin relativ neu mit dieser Umgebug. Kann dies zu Problemen führen? Dann kann ich ja sicher wieder auf npm 8.15.0 zurück.

[Thomas Braun]

@alexmi sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Kann dies zu Problemen führen?

Aus der Erfahrung: Früher oder später schon. Kommt drauf an wo und wie du diese Version ins System gekleistert hast.

[alexmi]

@thomas-braun vor ein paar Tagen über sudo npm install -g npm@latest
Sollte ich deiner Meinung zurück auf npm 8.15.0 ?