Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[crunchip]

@paul53 also zumindest, so wie ich es sehe, wird die objects.json in unregelmässigen Abständen geändert, also kein fester Zyklus. Jedoch noch keinen Grund gefunden.

Jetzt fasse ich aber trotzdem nochmal kurz zusammen.

• wie sich die objects.json vor dem 15.01.21 verhalten hat, weiß ich nicht
• seit dem 15.01. hab ich diese hohen i/o, davor lief alles piano, ohne Auffälligkeiten
• ab diesem Tag wurde der Js-controller und alle dazu benötigten Adapter(admin, web, socket...) upgedatet
• es kamen keine neuen Adapter dazu, es wurden lediglich, die Updates der bestehenden Adapter ausgeführt
• es wurden auch keine neuen Scripte erstellt, keine aktiviert oder geändert

wenn ich redis auch für Objekte aktiviere, sollte es vermutlich etwas besser laufen?

[Feuersturm]

Kann es auch hilfreich sein die Zeitplanung der einzelnen Instanzen zu prüfen / hinterfragen. Ich hab z.B. 5 ical Instanzen, welche bisher alle 15 min. gescheduled wurden. Gerade bei Geburtstagsterminen oder Müllkalendern ist ja sowas eher in der Häuffigkeit unnötig. Ich hab dies jetzt mal bei mir geändert und werde mal schauen ob und wie sich das Schreibverhalten ändert.

Meine "sdb" SSD ist jetzt seit knapp 4 Jahren im Einsatz und zeigt einen Wearout von 16% an.

Die "sda" SSD ist erst ein paar Monate alt.

Ich hab mit der Veröffentlichung von js-controller 3.2.x eine "ioBroker Testumgebung" aufgesetzt. Bei dieser habe ich aktuell folgende Schreibwerte:

[Homoran]

@martybr sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Ich werde trotzdem die SSD tauschen

Was habe ich denn jetzt nicht verstanden?
Ein Wearout von 3% in einem Jahr gibt rein rechnerisch noch eine Lebensdauer von 30 Jahren, bis der Wearout 100% erreicht hat

[JLeg]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@paul53 also zumindest, so wie ich es sehe, wird die objects.json in unregelmässigen Abständen geändert, also kein fester Zyklus. Jedoch noch keinen Grund gefunden.

Im Prinzip habe ich das gleiche Problem (zumindest in Bezug auf den Stress der SSD), object.json ist deutlich grösser als states.json, wird aber genauso oft neu geschrieben.
Theoretisch sollte sich ein Hinweis auf die Ursache finden lassen, wenn man die Unterschiede zwischen objects.json und objects.json.bak sinnvoll extrahieren könnte. Fürchte aber, da müsste man erst bissel basteln mit json und diff o.ä.

wenn ich redis auch für Objekte aktiviere, sollte es vermutlich etwas besser laufen?

Ja, da kannst du ja die Schreibfrequenz beliebig niedrig einstellen (allerdings auf Kosten der Datensicherheit - wenn die Kiste abschmiert mit 5 Minuten Daten im Redis-Ram, sind die dann halt weg. Muss man abwägen)

[crunchip]

@jleg muss ich mir mal durch den Kopf gehen lassen, ob ich die Objekte auch auf redis umstelle.

zu meinen Ausuferungen des i/o von 8G aufwärts, habe ich einen verdacht auf den Unifi Adapter.
Und zwar habe ich dieses gefunden, bzw ist gerade aufgetaucht, was zeitlich übereinstimmt. Ich kenne zwar die Meldung, bekomme sie aber nicht weg.

unifi.0	2021-01-22 21:19:02.936	error	(1876) Error: Login required. Check username and password.
unifi.0	2021-01-22 21:19:02.639	error	(1876) Error: Login required. Check username and password.

[MartyBr]

@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.

[saeft_2003]

@martybr

In dem Artikel ist aber nicht von % die rede.

"Der normalisierte Wert sinkt linear von 100 bis auf 1"

[JLeg]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@paul53 na bravo, die Nadel im Heuhaufen suchen
ich geh erstmal was essen

Ich 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

[MartyBr]

Hier die Werte bei Start und Stopp Corona Adapter:

[crunchip]

@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

[Homoran]

@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Keine Ahnung, was ‚ts‘ ist,

timestamps

1611347196916 = 22.01.2021 - 21:26:36

[crunchip]

@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]

@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...

[paul53]

@martybr sagte: investiere ich hier lieber in eine neue und größere SSD.

Das ist bei einer Samsung 970 Pro nicht nötig.

[JLeg]

@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]

@jleg hab @Dutchman mal Bescheid gegeben.

so nun hab ich aber immer noch so ca alle 15-16min eine Änderung. Hab ich DWD bzw Weatherunderground in Verdacht, da diese
a) mit dieser cron Zeit laufen,
b) die Tage enorme Errors geworfen haben

[Wildbill]

Ich habe für den DWD-Adapter mal hier ein Issue aufgemacht.

Gruss, Jürgen

[Homoran]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Hab ich DWD bzw Weatherunderground in Verdacht,

DWD läuft bei mir auch - aber unauffällig

[Wildbill]

@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]

@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