ioBroker sehr hohe Diskwrites in Proxmox

[apollon77]

@dr-bakterius wie gesagt aktuell ist das sehr schwer und aus dem Grund nutzen Adapter üblicherweise extendObject. In jedem Adapter hier mega viel Logik einzubauen macht keinen echten Sinn. Aber ja adapter die hier viel so machen könnten etwas ändern.

Generell aber:
Ja, das Thema ist bekannt und seid mindestens 1-2 Jahren genau so es gibt ein issue im js-Controller das zu optimieren und den Work around das writeFileInterval anzupassen (mit kleineren Risiken falls der Controller crasht was eher selten vorkommt). Wir überlegen mal für Controller 3.3 ob wir eine Lösung finden

[apollon77]

Ps: aber ja crib adapter sind in meinen Augen die einzigen die so ein behavior an den Tag legen dürfen ;-). Deamon Adapter sollten es nicht tun. Und wenn doch ist es bei denen ein issue Wert.

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

crib adapter sind in meinen Augen die einzigen die so ein behavior an den Tag legen dürfen ;-). Deamon Adapter sollten es nicht tun.

Gut, und jetzt steige ich aus...

[Homoran]

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

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

crib adapter sind in meinen Augen die einzigen die so ein behavior an den Tag legen dürfen ;-). Deamon Adapter sollten es nicht tun.

Gut, und jetzt steige ich aus...

Musst du nicht.
Den Ausdruck kannte ich bis eben auch nicht!
Aber wenn Daemon das Gegenteil ist, müssten crib-Adapter die scheduled Adapter, wie DWD/iCal usw. sein

[apollon77]

@dr-bakterius

Am Ende gibt es zwei Haupt-Typen von adaptersn: Schedule: Die werden zu definierten Zeiten gestartet (meistens Wetter adapter). "Deamon" Adapter sind die die man startet und die dann immer laufen. Die sollen bitte am Anfang einmalig Objekte anlegen und dann nur wenn nötig ist ändern. Da muss im Zweifel der Entwickler ran

[crunchip]

Da meine objects.json 32mb beträgt und bevor ich diese ebenfalls auf redis umstelle, habe ich nun mal "writeFileInterval": 3600000, für objekte hinterlegt, mal sehen wie sich das verhält. Zwischenzeitlich mach ich mir trotzdem mal Gedanken, ob und wenn ja, wie ich das am sinnvollsten umsetzten könnte.
mit aktueller Einstellung ergibt sich bei knapp einem Tag, folgender Wert

[Kueppert]

ich dachte eben noch: och, bei mir sieht das mit JS3.2 aber alles easy aus...nunja, 260 GB in 2 Tagen doch was mehr als ich dachte...schreibe aber auf 4 Platten, normale HDDs - ach kakke...stimmt nicht, ioBroker läuft auf ner SSD O.o

Sieht da für euch irgendwas schlimm aus?

[crunchip]

@kueppert alles im grünen Bereich

[Kueppert]

Ich hatte testweise den ioBroker auf die Synology (HDD) ausgelagert - war aber leider weniger performant als direkt auf ne SSD ^^ Habs daher wieder zurück gedreht (geht ja bei Proxmox - wenn man weiß wie zumindest - relativ flott -- hat bei mir nen halben Tag gedauert )

[ftd]

3,15 TB in 7 Tagen...

Übeltäter schon gefunden: DWD Cronjob stand auf 1 Minute, anstatt 1 Stunde. Mal schauen, was nach weiteren 7 Tagen da steht...

Wearout nach 3 Jahren ioBroker:

[saeft_2003]

@ftd

Steht bei dir dann 15% wearout unter disks?

[apollon77]

@ftdAuch wenn bissl off topic: Was auch immer der wearout Wert bei Proxmox bedeutet. Ich habe dazu ehrlich noch nie was klares gefunden. Man kann annehmen das das irgendwie sie SMART Werte nimmt und geschriebene Daten vs "maximal daten laut ssd datenblatt" ... keine Ahnung ...

[ftd]

@saeft_2003 Ja, die 15% stehen unter Disks.

@apollon77 Ich mach mir da nicht so den Kopf... die Platte kostet neu 30€. Backups über alles laufen problemlos... wenn Ausfall, dann austauschen, Backup zurückspielen, fertig.

@all Macht euch über die Wearouts nicht verrückt:

Samsung SSD EVO 850 (3,7 Jahre, 4% Wearout )

Crossair Force SSD (7,6 Jahre, 0% Wearout)

Samsung HD (11,6 Jahre, kein Wearout gelogged, summt im Dauerbetrieb wie ein Bienchen)

Zurück zum Topic: Seitdem der DWD nicht mehr minütlich schreibt, ist Ruhe bei den Diskwrites (da bei 24.01. gegen 00:00 Uhr die hellgrüne Linie):

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

irgendwie sie SMART Werte nimmt und geschriebene Daten vs "maximal daten laut ssd datenblatt"

Glaube ich nicht. Bei mir werden die geschriebenen Blöcke angezeigt, doch unter Wearout finde ich nur 'N/A'.

Und auch die 'Total_LBAs_Written' nehme ich Proxmox bzw. S.M.A.R.T. nicht ab. Da steht bei mir nach 19 Monaten Betrieb doch nur 19941. Umgerechnet sind das keine 10 MB! Das hat man nach wenigen Sekunden Betrieb schon beisammen.

Eine zweite (ältere) SSD wird mir mit 69661 (= 34 MB) angezeigt. tune2fs zeigt für die gleiche Platte aber 96 GB Lifetime writes an.

Also wirklich verlassen darf man sich auf die Werte nicht...

[apollon77]

Also meine LBAs Written sind etws höher ... aber ja keine Ahnung was der Wert genau bedeutet. Ich hoffe und vertraue da den SMART Werten das Sie mir rechtzeitig sagen und ja je nach SSD sinds 30-100 EUR grob ... und bei mir darf eine SSD bzw ein Node ohne auswirkungen ausfallen, also alles gut

[saeft_2003]

Der wearout von proxmox bezieht sich auf „ssd_life_left“ oder „media_wearout_indicator“
(Je nach Hersteller) hier sind 100 —> 0%, 85 —> 15% usw...

[Kueppert]

@ftd welche Datenpunkte greifst du hier über welchen Adapter ab??

PS: Ich liege immer noch bei 50 GB/Tag und weiß nicht, wo das her kommt ^^

[crunchip]

@kueppert gibts als fertiges proxmox Dashboard

[Kueppert]

@crunchip danke dir, aber ich nutze kein Grafana und dachte, ich visualisiere es mir selbst...hab nur keine passenden Objekte zum Loggen gefunden - außer proxmox.0.qemu_ioBroker.diskwrite

[crunchip]

@kueppert es gibt den ein oder anderen Adapter, der entsprechend die objekt.json neu schreiben lässt, beim ein oder anderen ist auch dort direkt Handlungsbedarf, wie z.b. WLED, hab dort schon Bescheid gegeben. Zum anderen ist ja, wie oben erwähnt, noch in Klärung, wie es gehandhabt wird mit Zustandsänderung(timestamp).

Andernfalls wurde auch der "workaround" genannt, nen Schreibintervall zu setzen, habe ich z.b. siehe