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

[crunchip]

@kueppert gibts als fertiges proxmox Dashboard

[Kueppert]

@crunchip danke dir, aber ich nutze kein Grafana und dachte, ich visualisiere es mir selbst...hab nur keine passenden Objekte zum Loggen gefunden - außer proxmox.0.qemu_ioBroker.diskwrite

[crunchip]

@kueppert es gibt den ein oder anderen Adapter, der entsprechend die objekt.json neu schreiben lässt, beim ein oder anderen ist auch dort direkt Handlungsbedarf, wie z.b. WLED, hab dort schon Bescheid gegeben. Zum anderen ist ja, wie oben erwähnt, noch in Klärung, wie es gehandhabt wird mit Zustandsänderung(timestamp).

Andernfalls wurde auch der "workaround" genannt, nen Schreibintervall zu setzen, habe ich z.b. siehe

[Kueppert]

@crunchip danke dir. Werde ich mal bei mir einfügen.
PS: bei 12 GB/Tag würde ich mir ja keine Gedanken machen ^^

NACHTRAG: hab den Code-Snippet auch mal bei mir eingefügt und schaue mir das Verhalten jetzt weiter an.

2. NACHTRAG: bei mir fällt auf, dass der WEBSPEEDY-Adapter zu hohen DISK-IOs führt (das einzige was mir bei DISK IO im Proxmox aufgefanne ist. Zeiten Ausschlag zum Lauf des Speedy passen zusammen). Muss aber nicht zu meinen 50 GB/Tag führen...

[oFbEQnpoLKKl6mbY5e13]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

...habe ich nun mal "writeFileInterval": 3600000, für objekte hinterlegt, mal sehen wie sich das verhält.

Hier muss ich mal nachfragen. Was bedeutet das genau?

1. Die ObjectsDB wird einmal die Stunde geschrieben, auch wenn keine Änderungen in der Zeit angefallen sind.

2. Die ObjectsDB wird nur dann einmal die Stunde geschrieben, wenn Änderungen angefallen sind.

3. Die ObjectsDB wird auch dann nur einmal die Stunde geschrieben, wenn in der Zeit beliebig viele Änderungen angefallen sind?

Ich vermute 3, richtig?

[apollon77]

@ofbeqnpolkkl6mby5e13 Sobald es eine Änderung gab läuft der Counter und dann werden alle Änderungen die ab dann bis zum Ablauf der 60 Mins aufgelaufen sind zusammen geschrieben

[crunchip]

@ofbeqnpolkkl6mby5e13 nur zur fest eingestellten Zeit.
Nachteil wurde ja oben ebenfalls erwähnt, wenn der controller sich mal verabschieden sollte, was aber seltenst vorkommt.

[oFbEQnpoLKKl6mbY5e13]

@apollon77
Danke, das ist eine gute Erklärung!

[oFbEQnpoLKKl6mbY5e13]

@crunchip
Ja, du hattest ja auch nur zum Testen auf 1 Stunde erhöht, wenn ich das richtig verstanden habe.

[crunchip]

@ofbeqnpolkkl6mby5e13 läuft auch weiterhin erstmal so weiter

[oFbEQnpoLKKl6mbY5e13]

Was würde überhaupt passieren, wenn es einen State gibt, zudem es kein Objekt gibt, weil die Änderungen nicht gespeichert werden konnten?

[apollon77]

@ofbeqnpolkkl6mby5e13 Naja in einer normalen Welt legt der Adapter vor dem Schreiben das Ojekt eh neu an. Also wenn der controller crasht und deswegen nichts geschrieben wird (wobei auch das versucht wird abzufangen), dann musst Du danach eh alles neu starten ...

Du verlierst nur potentiell Infos wie "adapter gestoppt/gestartet/anderer Host geschoben" oder "Custom Settings" von Objekten ...

[oFbEQnpoLKKl6mbY5e13]

@apollon77
Was ist mit selbst angelegten DPs?

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

wobei auch das versucht wird abzufangen

Im Container muss iobroker ja durch pkill gestoppt werden. Ist das problematisch?

[apollon77]

@ofbeqnpolkkl6mby5e13 Ja die sind auch weg

[apollon77]

@ofbeqnpolkkl6mby5e13 Ich sage ja - es "sollte" kein Problem sein...teste es ob er es sauber speichert

[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