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

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@ofbeqnpolkkl6mby5e13 Ja die sind auch weg

Das hatte ich verstanden. Meine Frage zielte darauf ab, was mit einem State passiert, zu dem es kein Objekt gibt, wenn es sich um ein Objekt handelt, was eben nicht durch einen Adapter sowieso wieder erstellt wird?

[Dr. Bakterius]

Nur mal kurz mein "Erfolg":

Durch Umstellung der States auf redis und die Änderung auf "writeFileInterval": 3600000, bei den Objects konnte ich die Datenmenge die von ioBroker geschrieben wird um über 90% reduzieren. Ich bin jetzt auf deutlich unter 20 GB am Tag. Zuvor hatte ich über 200 GB am Tag (lt. Proxmox)! Als Nebeneffekt wurde auch die Prozessorlast um ca. 30% verringert.

Schuld an den hohen Datenmengen waren bei mir die Adapter 'DasWetter' (weil per Cron gestartet und daher normal) und 'Netatmo' (dort habe ich ein Issue angelegt).

[Kueppert]

TADAA, bin auch mal auf REDIS abgewandert bzgl. der States (vorher via Proxmox nen Backup von meiner SQL- und ioBroker-VM gemacht). "writeFileInterval": 3600000, hatte ich schon gesetzt. Reduzierung von knapp 55 GB / Tag auf 12 GB / Tag.
Mit Redis bin ich gespannt, wie sich das Bild noch verändert und ob ich irgendwelche CPU-Last-Reduzierung wirklich erkennen kann.
REDIS lasse ich auch fein via BackItUp sichern (musste vorher sudo usermod -a -G redis iobroker noch das Recht einräumen, da BackItUp mit ein fehlendes Recht im Log gemeldet hatte).

Läuft das alles, werd ich mal mit InfluxDB spielen und von SQL dahin wandern (anderes Thema). WIll mal bissl mit Grafana rumspielen :)

[robbsen]

@kueppert

kannst du mir mal sagen welche Versionen du benutzt, benutzt du einen Container oder VM?
ich selber habe folgende Konstellation. Ich habe alle extra noch mal neu aufgesetzt und installiert.

Leider ergibt sich bei mir weiterhin ein tägliches Schreibvolumen von 434 GiB von 404 bzw. 434 GB/Tag
habe das mal als Exceltool gebaut, die Daten könnt ihr direkt in ioBroker über den Adapter Proxmox ablesen
megabyte.xlsx

• Proxmox 6.3.3
• Consummer SSD (Sandisk Plus)
• Node.js: v12.20.1
• NPM: 6.14.10
• Contrainer
• Redis (Objects und File)
• Influx als separater Container
• Objekte: 6054, Zustände: 4934

Irgendwie macht mir das doch Sorgen... überlege weiterhin mir ne Enterprise SSD zuzulegen. Rechnerssich ergibt sich bei mir eine SSD Lebensdauer von 0,4 Jahren --> hatte gehofft es ist nur ein Denkfehler. Aber offensichtlich haben ja viele hier viel geringere DiskWrites/Tag

[liv-in-sky]

@ftd

diese smart sache finde ich sehr interessant - würde mich auch interessieren

könntest du ein paar sachen dazu schreiben - man kann sicher bash scripte schreiben, um das in iobroker zu bekommen . was brauche ich dazu, um das zu sehen ? gibt es tools dafür

[Meister Mopper]

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

"writeFileInterval": 3600000,

Da habe ich mal zwei Fragen:
Wo wird das eingestellt? Ich finde einen derartigen Eintrag in der redis.conf gar nicht.
Ich schreibe meine states in redis, hilft da dieser Eintrag auch?

[crunchip]

@robbsen sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Redis (Objects und File)

Erläutere dies
Hast du beides auf redis umgestellt, state und object? Wenn ja greift, writeFileInterval nicht.

[crunchip]

@meister-mopper https://forum.iobroker.net/post/564759

[Meister Mopper]

@crunchip Ah super, hätte ich ja auch mal richtig suchen können :confounded:

[robbsen]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Erläutere dies
Hast du beides auf redis umgestellt, state und object? Wenn ja greift, writeFileInterval nicht.

hi crunchip habe beides umgestellt. Das writefileinterval dürfte also keinen Effekt haben.
Sehe das auch. Bei mir gibt es nur noch alle ca. 4 Minuten einen Schreibintervall. Allerdings ist dieser deutlich zu hoch

okkkk jetzt passt meine Logik überhaupt nicht.

Rechne ich das aus der Richtung (15 M) alle 4-5 Minuten hätte ich kein Problem....

das Thema macht mich noch wahnsinnig ^^

[Dr. Bakterius]

@robbsen sagte in ioBroker sehr hohe Diskwrites in Proxmox:

habe beides umgestellt.

Das hatte ich letztes WE auch versucht. Hat auch bei mir zu einer höheren Schreiblast geführt, weil redis die objects und states schreibt und somit mehr Daten zusammenkommen. Deswegen nur states auf redis und die objects per file alle Stunden sichern.

Bei der Rückkehr von redis zu file bei den objects, blieb die Datenmenge allerdings weiter so hoch weil die Datenbank offensichtlich nicht bereinigt wurde. Also den Snapshot von Proxmox wieder hergestellt und gut wars...

[ftd]

@liv-in-sky ja, https://www.smartmontools.org/ unter Linux oder https://www.hwinfo.com/ (Freeware) unter Windows

[Scrounger]

@liv-in-sky sagte in ioBroker sehr hohe Diskwrites in Proxmox:

könntest du ein paar sachen dazu schreiben - man kann sicher bash scripte schreiben, um das in iobroker zu bekommen . was brauche ich dazu, um das zu sehen ? gibt es tools dafür

Kannst den Linux Control adapter dafür verwenden.
Hier mal Bsp. wie ich das mache, allerdings ist das ne m.2 (nvme) und die liefert andere Werte. musst du dann halt noch entsprechend anpassen. Somit hat man die Werte in iob und kann sich daraus z.B. die theroretische Lebendauer bis der TBW erreicht ist errechnen:

wearout:

smartctl -a /dev/nvme0 | grep "Percentage Used:" | sed -e "s/[^0-9]/,/g" -e "s/,,*/,/g" -e "s/^,\|,$//g"

betriebszeit:

smartctl -a /dev/nvme0 | grep "Power On Hours:" | sed -e "s/[^0-9]/,/g" -e "s/,,*/,/g" -e "s/^,\|,$//g" | sed 's/,//g'

total bytes wirtten:

smartctl -a /dev/nvme0 | grep "Data Units Written:" | awk '{ print $5 }' | grep -Eo '[+-]?[0-9]+([.][0-9]+)?'

temperatur:

smartctl -a /dev/nvme0 | grep "Temperature:" | sed -e "s/[^0-9]/,/g" -e "s/,,*/,/g" -e "s/^,\|,$//g"

[robbsen]

@dr-bakterius ohhhh ok auf die Idee wäre ich nicht gekommen. Guter Hinweis.... dann werde ich mal neu installieren. Hatte ja bewusst alles neu installiert, wirklich bei 0 gestartet. Werde also versuchen neu zu installieren ober ohne Redis bei objects bei File... hoffentlich klappt es mit dem Backup einspielen.... Versuch macht klug

[robbsen]

@robbsen OK kurzer AH-Moment --> erklärt zumindest bei mir einiges. Ggf. auch bei einigen von euch ein Mitgrund...

ProxMox löscht keine Contrainer Statistik. Wird selbige Nummer noch mal verwendet bleibt die Statistik bestehen des alten Containers.
Ein vor 45 Minuten neu erstellter Container (Kopie einer frischen Installation) 23,65 GiB verbraucht.... das erschien mir unrealistisch. Ich konnte den Fehler replezieren.
https://forum.proxmox.com/threads/proxmox-4-reset-statistics-and-calculate-the-disk-space-new.28783/ Die Nummern werden ja wenn man einen Container löscht und einen neu erstellt neu vergeben

eindeutig stimmt da was nicht

.... heute erstellt Daten von vor zig Tagen

ja das ist ein Thema:
aktive Container

Container mit Statistiken

[crunchip]

@robbsen sagte in ioBroker sehr hohe Diskwrites in Proxmox:

ProxMox löscht keine Contrainer Statistik.

Es reicht die VM bzw LXC neu zu starten, somit wird von 0 gezählt

[crunchip]

@robbsen sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Die Nummern werden ja wenn man einen Container löscht

Wie löscht?
Kann grad nicht nachsehen, aber habe im Kopf...
Wenn du einen LXC oder VM löscht, kommt das Fenster zum Haken setzen (purge...)

[robbsen]

@crunchip @crunchip hi ja den Harken habe ich nicht gesetzt. Hab´s aber ausprobiert. Soweit ich es sehe löscht der Button "bereinigen" nicht die Statistik.
Dennoch hast du Recht, ein Neustart lässt den Counter von neuem starten.... und schon fängt ioBroker wieder fleißig an die Festplatte vollzuschreiben..

[saeft_2003]

Danke an alle! Ich konnte mein diskwirte von 3,5 M auf 1,5 M senken...

Ich habe die Intervalle von das Wetter, weatherunderground, corona-statistiks und web speedy angepasst. Die iobroker.json habe ich mit "writeFileInterval": 300000, angepasst.

Was auffällig war das der synology Adapter einen hohen diskwrite verursachen kann.

[Kalle Blomquist]

@saeft_2003 Hi, falls es von Interesse ist.

Diese Spitzen werden von linux-controle.0 bei mir erzeugt.
Je nachdem, wie man den Abfrage Intervalle festlegt.
Nach 23.02 Uhr in der Grafik habe ich linux-control.0 abgestellt.

Gruß Kalle