ioBroker sehr hohe Diskwrites in Proxmox
-
@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? -
@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 Ah super, hätte ich ja auch mal richtig suchen können
-
@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 ^^
-
@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...
-
@liv-in-sky ja, https://www.smartmontools.org/ unter Linux oder https://www.hwinfo.com/ (Freeware) unter Windows
-
@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" -
@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 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 Tagenja das ist ein Thema:
aktive Container
Container mit Statistiken
-
@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
-
@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...) -
@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.. -
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.
-
@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
-
@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
-
Die influxDB läuft zusammen mit grafana in einer anderen VM. Ich schau morgen früh mal nach wie viel die schreibt...
-
@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.
-
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-runnerLäuft das mit postfix?
-
@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 ...
