Monatsrückblick Januar/Februar 2026 ist online!

[stenmic]

Mein Diskwrite hat sich mit JS 3.2 und redis halbiert!
von 40 auf 18GB/Tag. Habe nichts an Config's geändert.
Habt ihr dafür eine Erklärung?

[Dr. Bakterius]

@stenmic sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Habt ihr dafür eine Erklärung?

Was möchtest du denn wissen?

[apollon77]

@stenmic Alles auf redis oder sind nur States auf Redis und objects weiterhin "file"? Wenn zweiteres dann ja, der controller hat was optimiert

[stenmic]

@apollon77 nur die States sind redis.
Danke für die Erklärung.

[saeft_2003]

Ich habe heute noch was herausgefunden. Ich habe das loglevel vom host in der iobroker.json von info auf warn gestellt. Das hat mein dikwrite von 500k auf 100k verringert :fearful:

Zugegeben ich habe gleichzeitig noch ein paar Adapter von info auf warn umgestellt, aber erfahrungsgemäß war doch der größte Teil im log vom host (info).

@apollon77 Könnte man es nicht einfacher gestalten den loglevel des host zu verändern? Weil ich denke nicht das der Standart User in der iobroker.json rumfummelt und ich denke auch das würde bei dem ein oder anderen die Lebenszeit der SD Karte verlängern. Was meinst du?

[amg_666]

@robbsen ich weiß nicht ob wir da jetzt Äpfel mit Birnen vergleichen aber bei meinem proxmox sieht das genauso aus wie bei dir, nur dass die Spitzen bei Diskwrite nicht bei 10-14M liegen sondern bei 100-120k ...

Also bei mir Intel NUC6, proxmox mit Debian 10 und iobroker als VM (2CPU, 8GB RAM) und ich habe noch keine weiteren Anwedungen drauf laufen (und nutze übrigens History). Das alles können natürlich mögliche Quellen sein, dass die Werte stark abweichen...

[Diginix]

@amg_666 Wenn er nur das Loglevel vom Host hochgesetzt hat, dann kann das vorher höhere Diskwrite schon vom Host und dessen "info" Zeilen im Log stammen. Müsste sich ja auch an der reinen Dateigröße der Logfiles erkennen lassen.
@saeft_2003 Wie groß sind denn deine Logs der letzten Tage? Und das von heute und zukünftige müssten dann deutlich kleiner ausfallen.

[foxriver76]

@saeft_2003 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Könnte man es nicht einfacher gestalten den loglevel des host zu verändern? Weil ich denke nicht das der Standart User in der iobroker.json rumfummelt und ich denke auch das würde bei dem ein oder anderen die Lebenszeit der SD Karte verlängern. Was meinst du?

Geht doch mit Admin 5

[saeft_2003]

@foxriver76

Ah ok ich habe noch kein Admin 5 im Einsatz. Dann sollte das ja für die Zukunft passen 👍

[saeft_2003]

@diginix sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@saeft_2003 Wie groß sind denn deine Logs der letzten Tage? Und das von heute und zukünftige müssten dann deutlich kleiner ausfallen.

Gezippt sind diese 5-6kb groß. Übermorgen habe ich einen kompletten Tag mit host auf warn dann kann ich sagen wie groß das log dann ist.

[Marty56]

Bei mir scheint der "Übeltäter" die Persistenz der Redis Datenbank zu sein.
Ich hatte die Defaultwerte mit 5 min bei geänderten 10 keys.

Ich habe die Backup Frequenz mehr als den Faktor 10 reduziert.

save 30000 1
save 3600 10
save 60 10000

[apollon77]

@marty56 ja das ist so eine sache. Aus dem Grund laufen bei mir zwei redis Instanzen und so objects und States getrennt. Objects mir aof persistent und States mit normaler persistent mit angepassten Werten. Das war bisher das optimum.

[Marty56]

@apollon77 Danke für den Hinweis.

Allgemein.

Vorab. Ich bewundere das Engagement von den vielen ehrenamtlichen Entwicklern und die tolle Leistung. Ich liebe iobroker immer noch, aber
die Komplexität von iobroker ist viel zu groß.

Es ist sehr bedauerlich, dass der Nutzer sich mit dieser Art von "Eingeweide"- Konfiguration überhaupt beschäftigen muss

Mich hat das Thema fast 2 h gekostet, bis ich den ganzen "Quatsch" mit der Redis Config für diese Spezialität so halbwegs verstanden und geändert hatte.

Außerdem hätte ich nicht Promox genutzt, dann wäre mir die SSD- Schreiberei gar nicht aufgefallen und z.B. auf einem Raspberry wäre mir die SD Karte nach einem halben Jahr abgeraucht. Ich hätte mich gewundert und beim nächsten Ausfall wäre ich vermutlich zu Amazon oder Google gewechselt und hätte zähneknirschend auf etliche Funktionen verzichtet.

Klar, wenn ich hauptberuflich Systemadministrator wäre, dann würde ich darüber nur schmunzeln und die Sache wäre in einer Minute erledigt.

So muss ich ein Know How aufbauen, was ich einmal in meinem Leben benötige, in einem Monat ohnehin wieder vergessen haben und bei der nächsten ioBroker Installation in 2 Jahren wiederholt sich dieser Prozess wieder. Das killt jegliche Produktivität.

So wird ioBroker leider nie Mainstream und nur nutzbar für Linux Admins und Nerds. Die Folge, die drei Gatekeeper, Apple, Google und Amazon werden sich den Markt unter sich aufteilen, mit schlechten Ansätzen dominieren und die IoT- Hersteller mit Lizenzen zu teuren Produkte zwingen.

Das ist sehr schade und eine verpasste Chance.

[Thomas Braun]

@Marty56
Viele Möglichkeiten ergeben quasi zwangsläufig eine höhere Komplexität.

Wenn du nur einen Radiobutton zur Verfügung stellst, dann ist das ganze halt wesentlich einfacher, du bist aber als User auf die beiden Einstellungen beschränkt. Wenn du alle Möglichkeiten zur Verfügung stellst kommst du auch mit einem simplen EIN/AUS-Schalter nicht mehr hin.

[crunchip]

@marty56 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Außerdem hätte ich nicht Promox genutzt, dann wäre mir die SSD- Schreiberei gar nicht aufgefallen

da ich alles getrennt laufen habe,
verglichen mit anderen CT's oder VM's , ist iobroker nicht der "Übeltäter", da hab ich z.b. beim unifi controller oder OMV die selben Werte, den "Abschuß" liefert meine Influx
bei aktuell knapp 24 Tagen Laufzeit

• iobroker 123GB
• influxDB 1.59TB

[apollon77]

@marty56 äääähhhmm. Das - vor allem in Kombi mit redis - kapiere ich jetzt nicht.

Wer bitte sagt das du redis nutzen sollst? Nur weil es geht?? Der Standard ist die file dB und die ist out of the Box da und ist für 99,x Prozent der User und use cases das sinnvolle.
Und mit der musst du dich um nichts kümmern.

Redis ist für Seeeehr speziellere Fälle. Gibt sogar einen forum Thread zu redis und wann es Sinn macht und was es zu beachten gibt.

Von daher muss ich das Feedback leider in der form entschieden zurückweisen. Vllt sind wir eher an dem Punkt das ioBroker schon an einigen Stellen Zuviel kann und dann „spielekinder“ ( ;-) ) Dinge tun weil sie halt gehen und sie denken es macht Sinn. Aber ehrlich: dann gilt durchaus „selber schuld“.

[Marty56]

@apollon77
Erstmal ich wollte niemanden verletzten. Falls ich das doch getan habe, bitte ich um Entschuldigung.

Ich habe redis nur aus einem Grund ausgewählt, weil ich gehofft habe, mit einer In-Memory DB das Wear-Out meiner SSD zu verlangsamen. Defakto habe ich - durch meine "nachlässige" Konfiguration - genau das Gegenteil erreicht.
Klar mein Fehler. Aber das war nicht mein Punkt. Mein Punkt ist, dass Otto Normaluser sich mit solchen Sachen überhaupt herumschlagen muss. Und wenn er das nicht macht, zerschießt er sich sein System nach kurzer Zeit.

Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis.

[foxriver76]

@marty56 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Der file-basierte Ansatz hat ja genau dasselbe Problem. Hier muss ich in irgendwelchen Json Files neue Felder einfügen, die das Schreiben reduzieren. Meines Wissen gibt es dafür auch kein selbsterklärendes UI.
Die Hürde ist ähnlich hoch, wie bei Redis.

Nö, mit Admin 5 kannst du das besagte JSON via UI modifizieren.

[BBTown]

@marty56
ich habe eher den Eindruck, dass Du dich aufgrund eines Wertes der dir aufgefallen ist (Wearout) künstlich verrückt machst, ohne dass irgend etwas los ist.

[EDIT]
auflschlussreich https://forum.iobroker.net/post/566162

[apollon77]

@marty56 an sich muss auch mit file dB niemand an dem Wert etwa ändern. Mit js Controller 3.2/3 haben wir hier optimiert. Und für Controller 3.4 stellen wir Vorauss auf jsonl um was dann nochmals optimiert.

Am Ende ist die Standardeinstellung ein Kompromiss zwischen wrong Datenverlust im Crash Fall und nicht Zuviel Schreiblast. Also auch wer an dem Wert rumdreht (und das „muss“ keiner) sollte verstehen was er da tut weil es Konsequenzen haben kann.

Von daher sieh es doch mal so: vllt gibt es ja einen Grund das bestimmte Einstellungen explizit nicht so einfach änderbar sind. ;-))