Uha, da verstehe ich nichtmal die Hälfte von
. Kurz zu meinem Setup:
Ich habe jetzt einfach Samba in einem debian lxc Container installiert. Da werden aber nichtmal täglich Daten geschrieben/gelesen. Das ist quasi meine Ablage für Fotos/Videos. Hier kommen wenn überhaupt mal alle paar Wochen ein paar GB auf die Platte. Diese wird dann per rsync gesichert. Auch das Ansehen der Daten passiert dann eigentlich auf einem der (insgesamt) 2 Backups.
Es passiert immer viel
Alleine dein Proxmox schreibt pausenlos Logs, Metrics und die HA Config Dateien jede Minute auf die SSD. Ist nicht unüblich, dass da Proxmox selbst schon 30GB am Tag auf die SSD schreibt, einfach nur so im Leerlauf um zu funktionieren. Deshalb soll man Proxmox auch nicht auf USB-Sticks installieren, weil die im Null-Komma-Nichts kaputtgeschrieben wären.
Die 600GB die da bei mir am Tag auf den Flash der SSDs geschrieben werden sind zu 90% auch nur Logs und Metrics die im laufenden Betrieb entstehen und wo ich eigentlich selbst nicht richtiges auf die SSDs speichere.
Mich würde noch interessieren, wie ich sowas ermitteln kann, wieviel GB beim Schreiben auf die SSD tatsächlich geschrieben werden, wie du beschrieben hast.
Du kannst z.B. mal iostat auf dem Proxmox Host installieren:
apt update && apt install sysstat
Wenn du dann z.B. auf dem Host
iostat 1200 2 ausführst und 20 Minuten wartest, dann kannst du sehen, was da innerhalb von 20 Minuten auf deine SSD geschrieben wurde.
Dann hast du aber immer noch nicht die Gesamtmenge die auf dem Flash landet, da das nur die Daten sind die auf die SSD geschrieben werden sollten, ohne aber die interne Write Amplification von der SSD. Für die echte Gesamtmenge an Writes musst du gucken, ob dir deine SSD da per SMART-Attribute etwas sagen kann. Also z.B. mal
smartctl -a /dev/sda ausführen und dann gucken, ob da die SSD dir sagen kann, was da in der Summe wirklich auf den NAND Flash geschrieben wurde. Wenn du das dann nocheinmal nach 24 Stunden ausführst und die Werte subtrahierst, dann kannst du ja sehen was die SSD tatsächlich in 24 Stunden geschrieben hat.
Bei mir hat die SSD z.B. diese SMART-Werte:
Code:
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 642965
243 NAND_Writes_32MiB 0x0032 100 100 000 Old_age Always - 1588571
Die kann man so interpretieren, dass da bis heute "Host_Writes_32MiB: 642965 * 32MiB = 19,62 TiB" vom Host auf die SSD geschrieben werden sollte. Interessanter ist aber der andere Wert. "NAND_Writes_32MiB: 1588571 * 32MiB = 48,48TiB" besagt, dass da 48,48TiB auf den Flash geschrieben wurden, um da die 19,62 TiB speichern zu können. Diese SSD hatte also im Schnitt eine interne Write Amplification von Faktor 2,47 (weil 48,48/19,62).
SMART ist aber leider nicht standardisiert, weshalb du nicht sicher sein kannst, ob dir deine SSD das überhaupt anzeigt, was die wirklich auf den Flash geschrieben hat oder die nur mitzählt, was da der Host auf die SSD schreiben wollte. Das hängt immer von dem jeweiligen SSD-Modell ab.
Ich gehe davon aus, dass man Discard bzw. Trim irgendwie konfigurieren muss, damit es in Proxmox genutzt wird?
Ja, sowohl in den Gästen selbst (z.B. per fstab in Linux) als auch in den Einstellungen zum virtuellen SCSI Controller falls du VMs verwendest. Und natürlich noch in Proxmox. Standardmäßig ist Discard in Proxmox und Debian z.B. deaktiviert, dass da die SSD nicht autoamtisch mitgeteilt bekommt, wann etwas auf der SSD gelöscht wurde. Wenn die SSD nicht weiß, ob etwas gelöscht wurde, dann läuft die irgendwann voll und hat keine leeren Flash-Zellen mehr, die z.B. für das Wear Leveling genutzt werden könnten. Auch bremst es die SSD dann aus, wenn alles voll ist, weil sie so schlechter interne Operationen zur Optimierung durchführen kann.
Alles andere (auch wenn ich es nicht verstehe) ist wahrscheinlich für mein Setup nicht nötig, wie gesagt, da passiert nicht viel. Ansonsten nutze ich den NUC (und damit die SSD) noch als OpenVPN Server, einen Windows Client für das HomeOffice und ich wollte mir mal PiHole ansehen. Bei PiHole kann ich mir vorstellen wird viel geschrieben aufgrund der logs, muss ich mir aber erstmal ansehen.
Danke!
Das du das nicht für dein Setup brauchst kann man so nicht sagen. Alle von mir genannten Punkte, bis auf das mit dem ZFS TXG Timeouts wenn du kein ZFS nutzt, kannst du auch bei dir anwenden, damit deine SSD länger lebt. Wenn du das alles ignorierst wird es trotzdem laufen, aber die SSD nutzt sich halt schneller ab. Ob sich für dich der zusätzliche Aufwand lohnt musst du dann selbst entscheiden. Am besten mal hochrechnen was deine SSD so im Jahr schreibt (über die Daten von den SMART-Attributen) und dann gucken wie lange die Leben würde. Wenn die 10 Jahre halten würde wäre es ziemlich unnötig da noch die Haltbarkeit zu optimieren. Wenn die wie bei mir kein Jahr halten würde, dann sollte man sich aber echt mit Optimierungen befassen, weil das sonst ziemlich teuer wird, wenn man jedes Jahr 1 oder 2 neue SSDs kaufen muss weil die so schnell verschleißen.
Besonders so Dinge wie das mit der "noatime" und "nodiratime" sind leicht zu erledigen und können viel bewirken. Nehmen wir mal an ein Programm von dir will eigentlich nichts schreiben, aber durchsucht alle Dateien, ob in einer von denen ein bestimmtes Wort steht. Hast du 1.000 Ordner und 100.000 Dateien auf der SSD, dann werden alle einmal geöffnet um zu gucken, was da in denen steht. Hast du atime und diratime aber nicht deaktiviert, dann muss Linux bei jedem Öffnen einer Datei mitloggen, wann genau die Datei oder der Ordner das letzte mal aufgerufen wurde. Da 100.000 Dateien geöffnet wurden muss dann automatisch 100.000 mal das neue Datum auf die SSD geschrieben werden.
Da hast du dann ungewollt 101.000 kleine Writes erzeugt, obwohl du nur etwas lesend öffnen wolltest. Sobald du noatime und nodiratime setzt versucht Linux nicht mehr das Datum des letztens Zugriffs mitzuloggen und du hast viel weniger Writes, da nicht jeder Lesevorgang auch automatisch einen Schreibvorgang verursacht.
Besonders bei SSDs kann das übel kommen, da SSDs nicht gut mit kleinen Writes umgehen können und die dann besonders schnell verschleißen.
Von solchen Optimierungen hast du halt echt unzählige in Linux, wo du ständig unwissend unnötige Schreibvorgänge erzeugst, obwohl du meinst, dass du ja eigentlich garnichts schreibst.
