ioBroker sehr hohe Diskwrites in Proxmox
-
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@paul53 na bravo, die Nadel im Heuhaufen suchen:confounded:
ich geh erstmal was essenIch hab‘ meine Nadel gefunden: es ist der WLED-Adapter bei mir, der permanent 3 „ts“-Attribute in der object.json ändert. Keine Ahnung, was ‚ts‘ ist, aber kein anderer Adapter macht das bei mir...
< "ts": 1611347233158, --- > "ts": 1611347196916, 425532c425532 < "ts": 1611347233313, --- > "ts": 1611347197059, 425736c425736 < "ts": 1611347233379, --- > "ts": 1611347197127@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
ch hab‘ meine Nadel gefunden: es ist der WLED-Adapter
habe zum Test, ebenfalls WLED deaktiviert und siehe da, Änderungen der objekcts.json sind deutlich weniger geworden
-
@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Keine Ahnung, was ‚ts‘ ist,
timestamps
1611347196916 = 22.01.2021 - 21:26:36
@homoran sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Keine Ahnung, was ‚ts‘ ist,
timestamps
Danke; dann habe ich eine Ahnung, was passieren könnte - WLED scannt alle 30 Sekunden (Default) das Netz nach WLED-Controllern (broadcast, bonjour oder sowas), und ‚findet‘ offenbar die vorhandenen immer neu - aktualisiert zumindest die Attribute für IP, Mac usw.
Nach Abschalten der Instanz ist bei mir jetzt auf jedenfall tatsächlich Ruhe... -
@homoran
Ich habe das ganze auch nicht vollständig verstanden. In einem Artikel wurde beschrieben, dass der Wert im Laufe der Abnutzung von 100% zu 0% wandert. Daher meine Reaktion. Da ich aber schon geplante hatte, den Speicher zu erweitern, investiere ich hier lieber in eine neue und größere SSD.Als einen Verursacher der hohen Schreiblast habe ich (bei mir) den Corona-Adapter:
Ich hatte mal einen Teil der Adapter gestoppt und sukzessive wieder gestartet. Ich verfolge das weiter.
P.S.
Ich Speicher die States in Reis. Der Remis-Server ist eine eigene VM. Diese läuft aktuell sogar auf einen anderen Host/Node. -
@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
ch hab‘ meine Nadel gefunden: es ist der WLED-Adapter
habe zum Test, ebenfalls WLED deaktiviert und siehe da, Änderungen der objekcts.json sind deutlich weniger geworden
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
ch hab‘ meine Nadel gefunden: es ist der WLED-Adapter
habe zum Test, ebenfalls WLED deaktiviert und siehe da, Änderungen der objekcts.json sind deutlich weniger geworden
Setz‘ in der WLED-Instanz das Scanintervall einfach auf 300 oder so, und der Spuk ist vorbei... :) Wenn man neue WLEDs anlernen will, kann man‘s ja wieder runtersetzen.
-
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
ch hab‘ meine Nadel gefunden: es ist der WLED-Adapter
habe zum Test, ebenfalls WLED deaktiviert und siehe da, Änderungen der objekcts.json sind deutlich weniger geworden
Setz‘ in der WLED-Instanz das Scanintervall einfach auf 300 oder so, und der Spuk ist vorbei... :) Wenn man neue WLEDs anlernen will, kann man‘s ja wieder runtersetzen.
-
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Hab ich DWD
bzw Weatherundergroundin Verdacht,DWD läuft bei mir auch - aber unauffällig
kein Support per PN! - Fragen im Forum stellen -
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton im Header. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Hab ich DWD
bzw Weatherundergroundin Verdacht,DWD läuft bei mir auch - aber unauffällig
@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. Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist wegen Schneefall seit heute Nacht. In den letzten Tagen hatte ich das viertelstündliche Speichern nicht, da gab es allerdings auch keine Meldungen.
Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat? Kann man das Intervall irgendwo sehen/einstellen?Gruss, Jürgen
-
@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. Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist wegen Schneefall seit heute Nacht. In den letzten Tagen hatte ich das viertelstündliche Speichern nicht, da gab es allerdings auch keine Meldungen.
Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat? Kann man das Intervall irgendwo sehen/einstellen?Gruss, Jürgen
@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist
dann werde ich das mal beobachten.
Kann natürlich wirklich sein, da dann die DPs neu befüllt werden.
Aber ist das so viel Info?BTW: ich habe die Karte nicht aktiviert
-
@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. Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist wegen Schneefall seit heute Nacht. In den letzten Tagen hatte ich das viertelstündliche Speichern nicht, da gab es allerdings auch keine Meldungen.
Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat? Kann man das Intervall irgendwo sehen/einstellen?Gruss, Jürgen
-
@wildbill sagte: Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat?
Gar nicht. Weshalb sollten konstante Objekte wiederholt gespeichert werden ?
@paul53 Meiner Meinung nach gar nicht, deshalb meine Frage. Wenn also die objects.json neu gespeichert wird, dann ist das ein Zeichen, dass irgend ein Datenpunkt neu erstellt oder ein bestehender geändert wurde. Beim Dwd bin ich mir dann sicher, aber ich beobachte mal weiter.
Gruß, Jürgen
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. Auch dazu gibt es ein Issue, evtl. hilft das ja eh besser. Vermutlich ist es beim Syno-Adapter (den ich aber nicht habe) auch so, und bei vielen anderen auch.
-
@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. Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist wegen Schneefall seit heute Nacht. In den letzten Tagen hatte ich das viertelstündliche Speichern nicht, da gab es allerdings auch keine Meldungen.
Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat? Kann man das Intervall irgendwo sehen/einstellen?Gruss, Jürgen
@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 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.
-
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Hab ich DWD
bzw Weatherundergroundin Verdacht,DWD läuft bei mir auch - aber unauffällig
@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 Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.
Gruß, Jürgen
@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.bakDer 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.
-
@jleg Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.
Gruß, Jürgen
@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. -
@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.@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:
mit Notepad++ plus Compare-Plugin verglichen
Danke für den Tipp - soeben installiert!
-
@paul53 Meiner Meinung nach gar nicht, deshalb meine Frage. Wenn also die objects.json neu gespeichert wird, dann ist das ein Zeichen, dass irgend ein Datenpunkt neu erstellt oder ein bestehender geändert wurde. Beim Dwd bin ich mir dann sicher, aber ich beobachte mal weiter.
Gruß, Jürgen
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. Auch dazu gibt es ein Issue, evtl. hilft das ja eh besser. Vermutlich ist es beim Syno-Adapter (den ich aber nicht habe) auch so, und bei vielen anderen auch.
@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!
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@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!
@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.
-
@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!
@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?
666
Online32.7k
Users82.5k
Topics1.3m
Posts