Storage Extrem Langsam

[Skankhunt42]

Moin zusammen,

ich habe aktuell Probleme mit zu langsamen Storage.
Ich habe die Vermutung, dass es an dem Dell H330 mini Controller liegt, kann dies jemand bestätigen und hatte das selbe Problem?
Verwendet wird ebend der H330 Mini im Dell R730 mit 2x Xeon E5-2650 v4 und 64 GB RAM.
Aktuell habe ich auf dem H330 ein RAID 1 fürs OS und 4 weitere Cruicial BX500 1TB SSDs als Non-RAID an Proxmox für ein ZFS Pool RAIDZ1 weiteregeben.

Benchmark einer Disk aus dem ZFS Pool:

root@MADLEN-PVE01:~# fio --ioengine=libaio --direct=1 --sync=1 --rw=read --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --time_based --name seq_read --filename=/dev/sda
seq_read: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=93.3MiB/s][r=23.9k IOPS][eta 00m:00s]
seq_read: (groupid=0, jobs=1): err= 0: pid=2312969: Fri Feb 24 11:19:52 2023
  read: IOPS=24.2k, BW=94.5MiB/s (99.1MB/s)(5672MiB/60001msec)
    slat (usec): min=7, max=1103, avg= 8.19, stdev= 4.62
    clat (usec): min=2, max=14275, avg=31.78, stdev=39.15
     lat (usec): min=33, max=14285, avg=40.15, stdev=39.59
    clat percentiles (usec):
     |  1.00th=[   29],  5.00th=[   29], 10.00th=[   29], 20.00th=[   30],
     | 30.00th=[   30], 40.00th=[   30], 50.00th=[   30], 60.00th=[   30],
     | 70.00th=[   30], 80.00th=[   31], 90.00th=[   32], 95.00th=[   33],
     | 99.00th=[   38], 99.50th=[   44], 99.90th=[  660], 99.95th=[  898],
     | 99.99th=[ 1139]
   bw (  KiB/s): min=81112, max=102288, per=100.00%, avg=96867.83, stdev=3393.08, samples=119
   iops        : min=20278, max=25572, avg=24216.94, stdev=848.26, samples=119
  lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 50=99.55%, 100=0.04%
  lat (usec)   : 250=0.07%, 500=0.20%, 750=0.05%, 1000=0.05%
  lat (msec)   : 2=0.03%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=12.33%, sys=28.78%, ctx=1452032, majf=0, minf=46
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=1452027,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=94.5MiB/s (99.1MB/s), 94.5MiB/s-94.5MiB/s (99.1MB/s-99.1MB/s), io=5672MiB (5948MB), run=60001-60001msec

Disk stats (read/write):
  sda: ios=1449076/2857, merge=0/9, ticks=46695/1310, in_queue=48982, util=99.96%

CrystalDisk Mark Screenshot aus einer Windows Server VM - Die extrem langsam reagiert:






Vielen Dank.

 

[aaron]

Cruicial BX500 1TB SSDs

Die sind nicht toll. https://geizhals.at/crucial-bx500-1tb-ct1000bx500ssd1-a2168439.html Wenn ich hier die richtige gefunden habe, verwendet die QLC Speicherzellen.

Mit ben BX500 hab ich selber keine Erfahrung, aber wenn die ähnlich wie die Samung 870 QVO sind, dann sind die beim Schreiben mitunter wirklich schrecklich, sobald der Cache voll ist.

Bezüglich RAIDz1, schau dir https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_raid_considerations an. Für VMs ist ein RAIDz nicht unbedingt die beste Wahl

Idealerweise nimmt man DC SSDs mit echter Powerloss Protection. Damit sollte es ganz ordentlich flutschen während der Consumer SSD markt ein ziemliches Minenfeld ist.

 

[Max Carrara]

@aaron ist mir zuvorgekommen

Habe in einem Review der BX500 folgendes gefunden:

Da wurde zwar eine kleinere BX500 getestet, aber der Graph zeigt trotzdem, dass die SSD einen massiven Performance-Einbruch hat, sobald der Cache voll ist. Da du bei deinem fio benchmark nur reads getestet hast, ist das anscheinend nicht aufgefallen. Der CrystalDisk benchmark ist ebenfalls vermutlich nicht lange genug gelaufen und ist dazu noch am ganzen pool verteilt, weswegen es nochmal länger dauert, bis die Caches aller vier SSDs voll sind.

 

[Skankhunt42]

Danke für eure Rückmeldung, es sollten wohl 3D-NAND TLC Chips sein.
Ich kann verstehen, dass die Schreibrate massiv einbrechen kann, sobald der Cache voll läuft aber. Die Reaktionszeit der VMs ist grottenschlecht.
Klicke ich auf das Windows Startmenü, dauert das 10 Sekunden oder mehr bis es sich öffnet, mit dem Fileexplorer und Dateien entsprechend genauso.
Das sollte eigentlich nicht normal sein.

 

[aaron]

Was passieren kann, vor allem wenn mehr VMs gleichzeitig laufen, dass die SSD immer gut zu tun hat und somit immer daran arbeitet, den Cache in den eigentlichen Speicher zu schreiben. Entsprechend reagiert sie dann mitunter auch langsam.

In einem reinen Desktop PC fällt das mitunter kaum auf, weil da nur hin und wieder sehr viel geschrieben wird. Für ein VM Storage ist das mit genügend Gästen drauf halt eine andere Geschichte

 

[Neobin]

Cruicial BX500 1TB

es sollten wohl 3D-NAND TLC Chips sein.

Die 1 und 2 TB Variante hat immer QLC-NAND:

Außerdem kommt bei den neuen Modellen mit 1 TB und 2 TB Microns 96-Layer-QLC-NAND zum Einsatz.

https://www.computerbase.de/2019-10/sata-ssd-crucial-bx500-1tb-2tb (Unten im Update.)

Die kleineren Varianten gibt es wohl sowohl mit TLC- als (mittlerweile) auch QLC-NAND.

 

[Dunuin]

Kann bezüglich Haltbarkeit der BX500 120/240GB mit TLC auch nicht gerade gutes mit ZFS berichten. Da sind schon 2 von 5 nach wenigen Monaten Nutzung kaputt, obwohl nicht viel geschrieben wurde (nur Systemplatten).

 

[Falk R.]

Danke für eure Rückmeldung, es sollten wohl 3D-NAND TLC Chips sein.
Ich kann verstehen, dass die Schreibrate massiv einbrechen kann, sobald der Cache voll läuft aber. Die Reaktionszeit der VMs ist grottenschlecht.
Klicke ich auf das Windows Startmenü, dauert das 10 Sekunden oder mehr bis es sich öffnet, mit dem Fileexplorer und Dateien entsprechend genauso.
Das sollte eigentlich nicht normal sein.

Eventuell kommt zu den langsamen SSDs noch etwas hohe CPU Überbuchung hinzu oder du nutzt CPU Typ KVM64, da bitte auf host wechseln, dann läuft Windows deutlich besser.

 

[Neobin]

Die VM-Config (qm config VMID) und der IO-Delay wäre interessant, ja.

 

[mr44er]

Ich weiß nicht wie die Crucials im Detail reagieren, aber generell knickt consumerzeug immer schnell ein.
Möglicherweise hilft es, den writecache zu deaktivieren. Klingt doof, aber ich empfehle folgende Lektüre: https://yourcmc.ru/wiki/Ceph_performance#Drive_cache_is_slowing_you_down

Writecache deaktivieren empfiehlt sich immer bei consumer-SSDs für Serveraufgaben, egal ob Stützkondensatoren da sind oder nicht und auch egal, ob die Schreibrate noch weiter einbricht, denn wenn der Strom mal ausfällt, ist die OSD dann wenigstens nicht kaputt bzw. geringerere Wahrscheinlichkeit für Datenverlust.
Und ja, mag sein dass man sie damit noch schneller grillt...aber man ist sich ja bewusst, dass es eben nur consumerzeug ist.

 

[news]

Ich verwende als Einstieg immer die Crucial MX500 Serie und modifiziere noch einige ZFS Einstellungen.
Die Crucial MX500 haben eine 4k Blockgröße und zfs set atime=off <pool>

 

[Falk R.]

Mit den Consumer SSDs geht das ein paar Monate gut und richtig schnell ist das nie.
Ich habe auch nach einem Jahr begonnen die billigen SSDs auszutauschen, weil die immer wieder extrem hohe Latenzen produziert haben.
Ich nehme jetzt lieber gebrauchte Enterprise SSDs, die kosten genau so viel wie neue Consumer aber liefern wesentlich bessere Performance ab bei deutlich mehr Haltbarkeit.

 

[Dunuin]

Mit den Consumer SSDs geht das ein paar Monate gut und richtig schnell ist das nie.
Ich habe auch nach einem Jahr begonnen die billigen SSDs auszutauschen, weil die immer wieder extrem hohe Latenzen produziert haben.
Ich nehme jetzt lieber gebrauchte Enterprise SSDs, die kosten genau so viel wie neue Consumer aber liefern wesentlich bessere Performance ab bei deutlich mehr Haltbarkeit.

Das gleiche hier. Darf man nur nicht zu oft empfehlen, weil man so schon schwer an wirklich günstige gebrauchte Enterprise SSDs kommt

 

[news]

Danke, nice.

 

[news]

Ich betreibe meine als ZSF special device und konnte so ZFS RaidZn mit 4 TB HDDs massiv beschleunigen.
Metadaten und kleiner Dateien können so auf einem SSD ZFS Verbund gespeichert werden.

 

[Skankhunt42]

Vielen Dank an alle für euren Input.
Kurz gesagt sind Consumer SSDs vor allem die BX 500 für einen Hypervisor einfach kacke. Ist notiert.

Kann jemand etwas über die Kingston DC500 sagen? Sind die da schon besser geeignet?

 

[aaron]

vor allem die BX 500

Ich würd da die Samsung 870 QVOs auch ganz dick anstreichen

Die Kingston DC500 hab ich selber noch nicht in den Händen gehabt, aber mir auch erst kürzlich angeschaut. Haben echtes Power Loss Protection und die Read oder Mixed Varianten haben entsprechend deutlich andere IOPS beim Schreiben und DWPD. Werden nicht die supertollen SSDs sein, aber sollten solide DC SSDs sein.
Hab sie im Support schon mehrmals in Kundensystemen gesehen.

Würd mich auch freuen, wenn da jemand Erfahrung aus erster Hand hat, vor allem, was die Performance angeht, wenn sIe im Dauereinsatz sind.

 

[Domi-S]

Hier ein Review der DC500M
DC500M
Denke da sind ein paar interessante Infos dabei.

 

[Skankhunt42]

Hallo zusammen,

ich hatte mir zwischenzeitlich noch 2x DC500M angeschafft und einen zweiten ZFS Pool angelegt.
Alle VMs die auf Latenz angewiesen sind habe ich dann mit der OS vDisk auf den zweiten ZFS Pool gepackt.

Nun bin ich dabei eine größere VM aus einem Backup wiederherzustellen.

Die OS Platte dieser VM liegt auf dem ZFS Pool 2 mit den DC500M, das läuft auch durch ohne Probleme und auch recht schnell.
Die VM hat dann allerdings noch eine zweite platte angebunden die 800Gb groß ist, diese liegt auf dem ZFS Pool 1 mit den Crucial SSDs.

Sobald das Backup soweit ist die 800GB Disk auf den Pool 1 zu schreiben sterben alle VMs! Nicht nur die VMs auf dem ZFS Pool 1 sondern auch alle Maschinen die auf dem ZFS Pool 2 liegen ?

Ich verstehe nicht warum VMs auf dem ZFS Pool 2 sind auch sterben.

I/O Delay während des Restores liegt bei ca. 30-40% und die CPU last bei 10%.
Vielleicht weiß dazu jemand mehr.
Danke.

 

[Falk R.]

Wenn der ZFS Cache von deinem langsamen Pool voll ausgelastet ist und der Storage Stack nichts mehr annehmen kann, weil die langsamen SSDs nicht nachkommen, entstehen halt extreme Warteschlangen. Das kann bei jedem Hypervisor zu einem gefühlten Freeze führen. Eigentlich sollte der Restore langsam weiter laufen und wenn er fertig ist auch wieder alles normal schnell sein. Da braucht man halt Geduld und alles ist extrem träge. Ich würde die langsamen SSDs nicht mehr mit ZFS nutzen, dann ziehen die den anderen Pool auch nicht so doll runter.