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

[JLeg]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@homoran Ich hab das Issue aufgemacht, weil meine objects.json genau alle 15min (das war der DWD-Intervall) und zwar zu den jeweils eingestellten krummen Minuten (4, 19, 34, 49,) gespeichert wurde. Seit ich den DWD-Adapter mal angehalten habe, war zwischen zwei Speicherintervallen ca. eine dreiviertel Stunde, in der zeit hab ich im iobroker aber auch was gemacht. Also kein Verdacht sondern definitiv der DWD der da auf jeden Fall (auch) schuld ist.

Ja, ist er - nach Abklemmen des WLED waren die nachfolgenden object.json-Änderungen tatsächlich auch bei mir vom DWD, kann man leicht sehen, wenn man sich die Unterschiede zwischen object.json und object.json.bak anzeigen lässt.

[Wildbill]

@jleg Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.

Gruß, Jürgen

[crunchip]

@homoran ja, seit dem update gibt es nur noch diese Meldung

dwd.0	2021-01-23 17:00:07.039	warn	(1763) slow connection to objects DB. Still waiting ...

[JLeg]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@jleg Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.

Gruß, Jürgen

jq - damit jeweils objects.json u. objects.json.bak konvertieren (nach "lesbar"), und per diff dann einfach anzeigen.

jq . objects.json > objects.pretty.json
jq . objects.json.bak > objects.pretty.json.bak
diff -u objects.pretty.json objects.pretty.json.bak

Der oben erwähnte Fehler im js-controller lässt sich auch gut erkennen, denn es lässt sich oft auch beobachten, dass objects.json zwar neu geschrieben wurde, die beiden Dateien aber 100% identisch sind.

[Dr. Bakterius]

@wildbill Ich habe die Dateien nach Windows kopiert und mit Notepad++ plus Compare-Plugin verglichen. Benötigt bei entsprechenden Dateigrößen aber auch Zeit. Und ich konnte zwischen aktueller Datei und Backup auch keine Unterschiede feststellen. Es scheint, dass es reicht die Objects nur "anzugreifen" um ein Speichern anzustoßen.

[Homoran]

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

mit Notepad++ plus Compare-Plugin verglichen

Danke für den Tipp - soeben installiert!

[apollon77]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

EDIT: @apollon77 hat das Issue soeben geschlossen, da es wohl eher ein Problem des JS-Controllers ist, der nicht prüft, ob States bereits existieren wenn sie mit setObject upgedated oder neu erstellt werden und auch speichert, wenn es gar keine Änderung gab.

... also wenn das aus meiner Antwort bei Dir angekommen ist dann hast Du es falsch verstanden!

Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt. Die Diskussion ob das so Sinn macht und ob das ein neues schreiben triggern sollte - das ist das was wir diskutieren müssen ... Gibt mehrere Blickrichtungen darauf!

[paul53]

@apollon77 sagte: Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt.

Das sehe ich auch so. Es sollte Aufgabe des Adapters sein, nur geänderte oder neue Objekte zu schreiben.

[JLeg]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt. Die Diskussion ob das so Sinn macht und ob das ein neues schreiben triggern sollte - das ist das was wir diskutieren müssen ... Gibt mehrere Blickrichtungen darauf!

Keine Frage, aber, die gerade diskutierten Fälle waren solche, bei denen es keinerlei Änderungen in der objects.json gab (also auch keine "ts"-Änderungen), aber trotzdem geschrieben wurde. D.h. objects.json und objects.json.bak sind exakt identisch. Die einzigen "Änderungen" sind in diesem Fall der Zeitstempel der beiden Dateien... ;)
Ich habe verstanden, dass das ursächlich an Adaptern liegen dürfte - die Frage wäre aber imo, ob es nicht "oben drüber" jemanden (Objektdatei-Schreibroutine) gibt, der das abfangen (und verwerfen) könnte?

[apollon77]

@paul53 das ist aber nicht so einfach oder viel Logik in jedem Adapter. Vor allem crib adapter haben dieses Problem weil sie jedes Mal alles prüfen müssen. Deswegen Überlegen wir was wir da tun können ;-) das Thema hat’s aber nicht in den 3.2er Controller geschafft. 3.3 dann vllt.

[Wildbill]

@apollon77 OK, möglicherweise habe ich da einen Denkfehler oder ein Verständnissproblem. Aber wie @JLeg schrieb: Wenn es KEINE Änderungen an den Objekten selbst gibt und von einem bestehenden Objekt sich nur der Zeitstempel ändert, weil es 1:1 von einem Adapter oder Skript nochmals "neu" erstellt wurde und sich somit nur der Zeitstempel ändert, dann verstehe ich nicht ganz, warum das dann neu gespeichert werden sollte. Gibt es dafür Anwendungsfälle oder eine schlüssige Begründung oder weil, wie Du geschrieben hast, alles jedes Mal komplett geprüft werden muss und die Systemlast dadurch zu stark steigen könnte? Ansonsten bin ich da auch der Meinung, der Controller sollte das eher abfangen. Etwas mehr Last sehe ich (zumindest auf eine potenten System abseits der Raspi&Co) als unkritischer als zu oft stattfindende (unnötige?!) Schreibzugriff auf die objects.json.
Würde da das Umstellen der Objekte auf redis (die states habe ich schon auf redis) etwas verbessern? Meine objects.json hat aktuell etwas über 15MB, landen da bei redis dann auch nur die "Änderungen" und es werden nur die paar kB geschrieben, die sich geändert haben?

Gruss, Jürgen

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt. Die Diskussion ob das so Sinn macht und ob das ein neues schreiben triggern sollte - das ist das was wir diskutieren müssen ...

Okay, das erklärt einiges. Was bleibt ist die Frage, warum die Timestamps überhaupt in den objects und nicht in den states gespeichert werden?

[apollon77]

@dr-bakterius naja weil der timestamp im
Objekt quasi die Version desselben ist (Objekt = die Definition). Der state hat den timestamp
Mit der letzten zustandsänderung des States.

[apollon77]

@wildbill hängt davon ab wie du die persistenz in deiner redis konfig machst. Bei rdb persistenz wird auch alles geschrieben in den definierten Zyklen. Bei aof werden Änderungen nur angehängt und dann regelmäßig konsolidiert.

Effektiv wie gesagt kann man das Setting writeFileInterval bei den Dbs anpassen.

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

weil der timestamp im Objekt quasi die Version desselben ist (Objekt = die Definition).

Bedeutet das, dass hier der Adapter jeweils die bereits vorhandenen Objekte neu erstellt und daher der Timestamp der Objekte neu erstellt wird und sich daher unterscheidet? Der Entwickler müsste den Adapter also dahingehend anpassen, dass nur nicht vorhandene Objekte erstellt werden. Habe ich das richtig verstanden?

[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... :relieved:

[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... :relieved:

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 :-)