Neues YouTube-Video: Visualisierung im Devices-Adapter

[MartinP]

Data Units Read: 76,165,512 [38.9 TB]
Data Units Written: 355,179,743 [181 TB]

Das würde ja bedeuten, dass etwa 4/5 der Daten geschrieben, aber danach nie wieder gelesen werden?

Oder habe ich da einen Denkfehler?

[Dr. Bakterius]

Ich bin nach knapp einem Jahr bei 7% Verschleiß. Ich habe eine Samsung 990 Pro mit 1 TB. Es kommt auf den Hersteller und die angegebene TBW an. Bei meiner sind das 600 TB, also 600 Schreibzyklen. Also je nach Hersteller und Größe hält eine SSD / NVMe länger oder kürzer. Ich lasse mir den Wearout in einen Datenpunkt schreiben und mich benachrichtigen wenn er sich ändert. So kann ich das nicht aus dem Auge verlieren. Wobei so ein Speicher nach erreichen der 100% nicht unbedingt defekt sein muss. Manche halten noch deutlich länger.

[paul53]

@MartinP [sagte]: etwa 4/5 der Daten geschrieben, aber danach nie wieder gelesen werden?

IoBroker schreibt regelmäßig die Objekt- und Zustandsdaten, liest sie aber nur bei Neustart ein. Während des laufenden Betriebs werden die Daten im RAM gehalten.

[Meister Mopper]

@MartinP sagte:

Das würde ja bedeuten, dass etwa 4/5 der Daten geschrieben, aber danach nie wieder gelesen werden?

Es ist ein HA-Cluster und das Ergebnis entsteht aufgrund der viertelstündlichen Replizierungen.

[Thomas Braun]

Bei Proxmox muss man aber auch berücksichtigen:

Sudden Increases: Drastic jumps in wearout (e.g., from 0% to 98% in weeks) usually indicate excessive, often hidden, write amplification, frequently seen in virtualized environments (Proxmox/ZFS) with heavy logging or improper sync settings.

https://forum.proxmox.com/threads/nvm-ssd-extreme-high-wearout.143823/

[arteck]

@OliverIO ich hab ein ceph cluster da geht schon was durch die Leitung und i/o auf die Platten um die Nodes synchron zu halten

die WD Black SN750 NVMe war 6 Jahre

verbaut also.. ja es war Zeit :-)..hab mich ehh gewundert, dass die so lange gehalten hat

habs aber nicht auf dem Schirm gehabt

[arteck]

@paul53 sagte:

IoBroker schreibt regelmäßig die Objekt- und Zustandsdaten, liest sie aber nur bei Neustart ein. Während des laufenden Betriebs werden die Daten im RAM gehalten.

nicht ganz .. sonst währe alles weg bei Systemabsturz.. logisch oder

[paul53]

@arteck [sagte]: sonst währe alles weg bei Systemabsturz..

Deshalb werden die Daten regelmäßig (alle paar Sekunden) geschrieben, damit nach Systemabsturz zeitnahe Daten vorhanden sind.

[Negalein]

@Dr.-Bakterius sagte:

Ich lasse mir den Wearout in einen Datenpunkt schreiben und mich benachrichtigen wenn er sich ändert.

Hab das Thema gerade entdeckt.

In Proxmox sagt er 0%.
Aber im Adapter sagt er 100%.

Wo holst du dir die Daten?

[MartinP]

Wäre es unter dem Gesichtspunkt nicht interessant, eine billige, kleine SSD für diese Art von Daten zu nutzen?
Ist Geschwindigkeit hier ein Thema?
Wenn sowieso im RAM zwischengespeichert wird, halte ich das für nicht sehr wahrscheinlich.

Eine fette SSD, die "alles" enthält zu ersetzen ist sicherlich teurer, als wenn man die Abnutzung verursachenden häufig geschriebenen Daten auf eine kleinere, billigere SSD auslagert ...

Durch "Wear Leveling" kann das Thema aber durchaus kniffelig einzuschätzen werden. Es könnte sein, dass eine kleine prall gefüllte SSD deutlich schneller kaputt geht, als eine große SSD mit viel freiem Platz für Wear Leveling

https://en.wikipedia.org/wiki/Wear_leveling

[Eduard77]

@MartinP
ich habe bei mir vor 3 Jahren eine billige SSD verbaut.
Die SSD hat damals nur 18 Euro gekostet.

[MartinP]

Meine war auch nicht besonders teuer, da ich noch weiteres Zeug auf dem Mini-PC hoste habe ich mir aber was gegönnt und einen 480 GB SATA SSD genommen ;-)

28000 "Power-On-Hours" entsprächen auch etwa 3 Jahren.

Ich nutze keine Redis DB, wie sieht es bei Dir aus?

etwa 20,7 TB wurden wohl geschrieben.

[Eduard77]

@MartinP
Ich nutze auch kein Redis und habe nur 5 LXC Container.

[MartinP]

"Total_LBAs_Written" ist bei Dir um GRÖSSENORDNUNGEN kleiner, als bei mir

163062 wären bei 512 Byte LBAs ca 83 MByte, die geschrieben wurden ... mit 4096 Bytes LBA-Größe wäre die Zahl nicht viel realistischer ...

EDIT:
Es scheint SSDs zu geben, die den Zähler in GB auflösen.

https://serverfault.com/questions/992698/unit-for-total-lbas-written-in-smart-data

163 062 000 000 000 bei Dir

22 275 122 659 840 (=43506098945 x 512)

oder

178 200 981 278 720 (=43506098945 x 512)

bei mir ...

Könnte also ähnlich sein

[emil70]

@Negalein sagte:

Hab das Thema gerade entdeckt.

In Proxmox sagt er 0%.
Aber im Adapter sagt er 100%.

Bei mir zeigt er in Proxmox 4 % an und im Adapter 96%

Ich denke im Proxmox Adapter wird der freie Platz angezeigt

[MartinP]

4% + 96% = 100%

Meine Vermutung:

96% ist die "Rest-Fitness" der SSD, 4% der Abnutzungsgrad...

100% - Rest-Fitness = Abnutzungsgrad.

[arteck]

@Negalein das ist richtig die API liefert die restliche Lebensaduer.. also 100 % .. im Proxmox ist bei 0% = 100 %..

@MartinP sagte:

96% ist die "Rest-Fitness" der SSD, 4% der Abnutzungsgrad...

100% - Rest-Fitness = Abnutzungsgrad.

genau so

[Dr. Bakterius]

@Negalein sagte:

Wo holst du dir die Daten?

ich schreibe mir den Wearout mit einem kleinen Bash-Script das im Host per Cron regelmäßig ausgeführt wird in einen Datenpunkt von ioBroker.

#!/bin/bash

# Restliche vermutete Lebensdauer der SSD auslesen.
 wert=$(smartctl -a /dev/nvme0 | grep 'Percentage Used:' | awk '{print $3}')
 wert=$(echo "${wert%?}")
((wert=100-$wert))
	 
# In Datenpunkt von ioBroker schreiben
 Erg=$(curl -s http://192.168.1.101:8087/set/0_userdata.0.Disk_Restlebensdauer?value=$wert)

In deinem Fall macht das aber vielleicht sowieso der Adapter. Wenn Proxmox mal mehr als 0 anzeigt, dann schau nach was der Adapter anzeigt. (z.B. 2 -> 98).

[bahnuhr]

@MartinP
die Rest-Fitness (96%) bekomme ich auch angezeigt;
die Abnutzung (4%) jedoch nicht.

Welche Häkchen hast du in der Instanz angeklickt ?
Bitte kurze Rückinfo.
Danke.

[arteck]

@bahnuhr rechnen kannst du aber oder

100% - 96% = naaaaaaaaaaaaaa wie viel ist es den ???

der adapter ezeigt nur die rest Lebensdauer an von 100% ausgehend