ioBroker sehr hohe Diskwrites in Proxmox

[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

[crunchip]

@saeft_2003 hast du influxDB mit auf iobroker laufen oder separat?
Mittlerweile hab ich nen Stand, das Influx mehr als 3mal soviel schreibt wie Iobroker

[saeft_2003]

@crunchip

Die influxDB läuft zusammen mit grafana in einer anderen VM. Ich schau morgen früh mal nach wie viel die schreibt...

[saeft_2003]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@saeft_2003 hast du influxDB mit auf iobroker laufen oder separat?
Mittlerweile hab ich nen Stand, das Influx mehr als 3mal soviel schreibt wie Iobroker

Also die grafana/influxdb VM ist bei mir total harmlose. Die hat über 2 Tage und 5 Stunden einen diskwrite von 11 GB.

[Meister Mopper]

Mal eine Frage in diesem Zusammenhang. Hat jemand von euch das E-Mail Feature bei Fehlern unter Proxmox eingerichtet?
Ich meine diesen Eintrag in der smartd.conf:

DEVICESCAN -m mail-adresse@mail.com -M exec /usr/share/smartmontools/smartd-runner

Läuft das mit postfix?

[apollon77]

@saeft_2003 Aber nicht das Ihr hier Äpfel mit Birnen vergleicht oder ?! ... Wenn geht es doch darum wieviele States und Update Frequenz in der InfluxDB gespeichert werden ...

[crunchip]

@apollon77 mir ging es nur darum zu zeigen, das man unterscheiden muss, nicht das jemand daher kommt, hey meine iobroker VM hat xy diskwrites, aber nicht beachtet, das er noch influx, grafana und sonst was, mit auf der VM laufen hat.

[robbsen]

Wollte noch mal einen Status geben. Ich habe wirklich einiges noch mal neu gemacht. Es hat einiges gebracht, wenn noch nicht den Durchbruch.

Vorher lag ich bei 261 GB bzw. 97.420 GB/Jahr und damit einer rechnerischen Lebensdauer < 1 Jahr

Zwischenzeitlich liege ich bei Daten von 57 GB /Tag bzw. 20.769 GB/Jahr, damit ergibt sich eine rechnerische SSD Lebensdauer von 3,5 Jahre

• Neuinstallation
• Altes Backup eingespielt um die Komplettumstellung von States und Obcects Redis auf Objects Type: file & States Type: redis zu ermöglichen
• Objekte manuell aufgeräumt.
• Skripte aufgeräumt
• Influx separat (ca. 1 GB pro Jahr zusätzlich)

Next Steps:

• Umstellung der Write Intervalle wie oben von einigen erwähnt
• Blockly bauen um Festplattenlebensdauer anzuzeigen
• Überlegen ob ich meine komplette ProxMox Festplatte manuell sicher

[Kueppert]

Ich habe auch die States auf Redis umgestellt und den o. g. Timer auf diese 36000xxxx umgestellt.
Hat bei mir dazu geführt, dass anstatt 50 GB/TAG nun nur noch 12-15GB/TAG geschrieben werden auf die SSD im NUC.
Parallel sichere ich diese aber auch jede WOche noch mal separat auf meinen NAS. Da sind HDDs drin, die sollten halten ^^

[robbsen]

Hallo Zusammen,

kurze Frage noch ihr verwendet sehr unterschiedliche Write Intervalle. Ich vermute einige weil sie kein Redis benutzten für die States und andere für die Objekte?
wo genau wird es nun seit dem Jason Controller eingebaut?

einfach irgendwo folgendes dazwischen? "writeFileInterval": 3600000, ? oder habt ihr folgendes abgeändert: " "period": 120," auf alle xxx?

},
  "objects": {
    "type": "file",
    "typeComment": "Possible values: 'file' - [port 9001], redis - [port 6379], couch - [port 5984].",
    "host": "0.0.0.0",
    "port": 9001,
    "user": "",
    "pass": "",
    "noFileCache": false,
    "connectTimeout": 2000,
    "backup": {
      "disabled": false,
      "files": 24,
      "filesComment": "Minimal number of backup files, after the deletion will be executed according to backupTime settings",
      "hours": 48,
      "hoursComment": "All backups older than 48 hours will be deleted. But only if the number of files is greater than of backupNumber",
      "period": 120,
      "periodComment": "by default backup every 2 hours. Time is in minutes. To disable backup set the value to 0",
      "path": "",
      "pathComment": "Absolute path to backup directory or empty to backup in data directory"
    },

kueppert schrieb
"writeFileInterval": 36000xxxx,

paul53
"writeFileInterval": 300000,

crunchip
Da meine objects.json 32mb beträgt und bevor ich diese ebenfalls auf redis umstelle, habe ich nun mal "writeFileInterval": 3600000, für objekte hinterlegt,

Dr-Bakterius
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.