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

[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

[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