NEWS
ioBroker sehr hohe Diskwrites in Proxmox
-
In dem Artikel ist aber nicht von % die rede.
"Der normalisierte Wert sinkt linear von 100 bis auf 1"
-
@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:
@paul53 na bravo, die Nadel im Heuhaufen suchen
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
-
Hier die Werte bei Start und Stopp Corona Adapter:
-
@jleg guter Hinweis, den hab ich auch laufen und zufälligerweise die Tage festgestellt, das Wled nicht soooooo ganz korrekt läuft, gab doch da vor kurzem ein Update, wegen 3 Attribute zwecks Firmware 0.11
-
@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Keine Ahnung, was ‚ts‘ ist,
timestamps
1611347196916 = 22.01.2021 - 21:26:36
-
@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
-
@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... -
@martybr sagte: investiere ich hier lieber in eine neue und größere SSD.
Das ist bei einer Samsung 970 Pro nicht nötig.
-
@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.
-
-
Ich habe für den DWD-Adapter mal hier ein Issue aufgemacht.
Gruss, Jürgen
-
@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
-
@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
-
@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.
-
@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.
-
@jleg Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.
Gruß, Jürgen
-
@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 ...
-
@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.