Schlechte Performance von SSD Speichern

[Byolock]

Hallo zusammen,

mir ist aufgefallen das die Performance der Datenspeicher weit unter dem ist was ich erwarten würde. Ich habe 2 Datenspeicher Eingerichtet:

NVME SSD Pool (ZFS Mirror) :
1x SAMSUNG MZVLQ1T0HALB-00000
1x KINGSTON SNV2S1000G

SATA SSD Pool (Ext4 formatiert) :
Verbatim Vi550 S3

SMART Werte sehen bei allen SSDs noch gut aus. Bei beiden Datenspeichern bekomme ich nur werte weit unter den erwarteten heraus. Während man bei dem NVME Pool noch die Schuld auf ZFS schieben könnte, macht dies bei dem in Ext4 formatierten Pool keinen Sinn. Ich glaube daher das ich ein anderes Grundsätzlicheres Problem Habe.

Meine Restliche Hardware / Software Konfiguration :
CPU : Intel(R) Core(TM) i3-12100
RAM : 48GB DDR4 400mhz
Alle SSDs sind direkt am Mainboard angeschlossen.
Proxmox Version : 7.3-3

Im folgenden nun ein paar Benchmarks, der Verwendeter Benchmark Befehl ist :


fio --filename=/<path-to-storage>/fio.dat --size=1G --rw=write --direct=1 --bs=4k --ioengine=libaio --numjobs=1 --group_reporting --name=write --iodepth=16


NVME SSD Pool:

write: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.25
Starting 1 process
write: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1)
write: (groupid=0, jobs=1): err= 0: pid=386431: Mon Jan  2 16:41:43 2023
  write: IOPS=274k, BW=1070MiB/s (1122MB/s)(1024MiB/957msec); 0 zone resets
    slat (nsec): min=1943, max=6504.7k, avg=3268.29, stdev=27703.85
    clat (nsec): min=605, max=6676.7k, avg=54891.30, stdev=109587.60
     lat (usec): min=2, max=6679, avg=58.19, stdev=113.24
    clat percentiles (usec):
     |  1.00th=[   37],  5.00th=[   37], 10.00th=[   37], 20.00th=[   38],
     | 30.00th=[   38], 40.00th=[   40], 50.00th=[   45], 60.00th=[   47],
     | 70.00th=[   48], 80.00th=[   51], 90.00th=[   65], 95.00th=[  102],
     | 99.00th=[  208], 99.50th=[  253], 99.90th=[ 1516], 99.95th=[ 2212],
     | 99.99th=[ 5800]
   bw (  MiB/s): min= 1179, max= 1179, per=100.00%, avg=1179.09, stdev= 0.00, samples=1
   iops        : min=301848, max=301848, avg=301848.00, stdev= 0.00, samples=1
  lat (nsec)   : 750=0.01%
  lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 50=78.82%, 100=16.07%
  lat (usec)   : 250=4.57%, 500=0.25%, 750=0.07%, 1000=0.05%
  lat (msec)   : 2=0.10%, 4=0.05%, 10=0.02%
  cpu          : usr=9.31%, sys=76.26%, ctx=1023, majf=0, minf=12
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=1070MiB/s (1122MB/s), 1070MiB/s-1070MiB/s (1122MB/s-1122MB/s), io=1024MiB (1074MB), run=957-957msec

Das Ergebnis sieht erstmal nicht so schlecht aus, aber ich habe in VMs deutlich schlechtere Schreibraten bemerkt, daher den Test nochmal mit 6GB wiederholt:

write: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=305MiB/s][w=78.0k IOPS][eta 00m:00s]
write: (groupid=0, jobs=1): err= 0: pid=325411: Mon Jan  2 16:33:24 2023
  write: IOPS=53.6k, BW=209MiB/s (219MB/s)(6144MiB/29351msec); 0 zone resets
    slat (nsec): min=1988, max=4959.8M, avg=18039.28, stdev=4324848.25
    clat (nsec): min=938, max=4960.7M, avg=280201.83, stdev=16750357.26
     lat (usec): min=3, max=4960.8k, avg=298.29, stdev=17299.74
    clat percentiles (usec):
     |  1.00th=[   37],  5.00th=[   38], 10.00th=[   39], 20.00th=[   41],
     | 30.00th=[   53], 40.00th=[   69], 50.00th=[  141], 60.00th=[  200],
     | 70.00th=[  273], 80.00th=[  334], 90.00th=[  433], 95.00th=[  562],
     | 99.00th=[  963], 99.50th=[ 1287], 99.90th=[ 4146], 99.95th=[ 5473],
     | 99.99th=[12125]
   bw (  KiB/s): min=75000, max=440064, per=100.00%, avg=269632.17, stdev=71893.93, samples=46
   iops        : min=18750, max=110016, avg=67408.04, stdev=17973.48, samples=46
  lat (nsec)   : 1000=0.01%
  lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 50=28.16%, 100=18.84%
  lat (usec)   : 250=19.31%, 500=26.95%, 750=4.28%, 1000=1.58%
  lat (msec)   : 2=0.58%, 4=0.20%, 10=0.09%, 20=0.01%, 50=0.01%
  lat (msec)   : 100=0.01%, >=2000=0.01%
  cpu          : usr=3.36%, sys=26.16%, ctx=50099, majf=0, minf=15
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1572864,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=209MiB/s (219MB/s), 209MiB/s-209MiB/s (219MB/s-219MB/s), io=6144MiB (6442MB), run=29351-29351msec

200MB/s ist deutlich unter dem Was ich hier erwarten würde, beide NVME SSDS sollten mit über 1000MB/s Sequentiell Schreiben können. Nun handelt es sich ja um ein ZFS Mirror, es liegt also nahe den Fehler bei ZFS oder der Tatsache das zwei unterschiedliche Modelle im Mirror betrieben werden zu suchen. Daher habe ich mir im folgenden mal die einzelne SATA SSD angeschaut.

SATA SSD Pool :

write: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=132MiB/s][w=33.7k IOPS][eta 00m:00s]
write: (groupid=0, jobs=1): err= 0: pid=312137: Mon Jan  2 16:26:14 2023
  write: IOPS=21.3k, BW=83.0MiB/s (87.1MB/s)(1024MiB/12333msec); 0 zone resets
    slat (nsec): min=645, max=973623, avg=5100.15, stdev=5524.90
    clat (usec): min=44, max=385613, avg=747.02, stdev=3700.92
     lat (usec): min=50, max=385618, avg=752.19, stdev=3701.11
    clat percentiles (usec):
     |  1.00th=[   184],  5.00th=[   221], 10.00th=[   229], 20.00th=[   235],
     | 30.00th=[   241], 40.00th=[   251], 50.00th=[   269], 60.00th=[   318],
     | 70.00th=[   441], 80.00th=[   603], 90.00th=[  1029], 95.00th=[  1532],
     | 99.00th=[  9241], 99.50th=[  9765], 99.90th=[ 10945], 99.95th=[ 11600],
     | 99.99th=[139461]
   bw (  KiB/s): min= 8544, max=138560, per=98.39%, avg=83653.67, stdev=46111.25, samples=24
   iops        : min= 2136, max=34640, avg=20913.42, stdev=11527.81, samples=24
  lat (usec)   : 50=0.01%, 100=0.05%, 250=39.20%, 500=36.05%, 750=11.15%
  lat (usec)   : 1000=3.29%
  lat (msec)   : 2=6.53%, 4=0.13%, 10=3.19%, 20=0.37%, 100=0.02%
  lat (msec)   : 250=0.01%, 500=0.01%
  cpu          : usr=2.51%, sys=12.83%, ctx=201519, majf=5, minf=12
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=83.0MiB/s (87.1MB/s), 83.0MiB/s-83.0MiB/s (87.1MB/s-87.1MB/s), io=1024MiB (1074MB), run=12333-12333msec

Disk stats (read/write):
  sdf: ios=20/255728, merge=0/58, ticks=75/187861, in_queue=187960, util=98.06

Die Vi550 S3 ist nun auch kein High End Modell, aber nur 13 von 125GB sind belegt. Auf diesem Storage liegen nur ISOs und Templates keine VM läuft dort aktiv. Ein 1GB Schreibbenchmark sollte hier definitv in den SLC Cache passen, und selbst wenn dies nicht der Fall wäre sollte laut online Tests trotzdem eine Geschwindigkeit um ca 500MB/s gehalten werden. Zum Test habe ich hier mal auch ein Read Test gemacht :

write: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=155MiB/s][r=39.7k IOPS][eta 00m:00s]
write: (groupid=0, jobs=1): err= 0: pid=402382: Mon Jan  2 16:45:26 2023
  read: IOPS=39.9k, BW=156MiB/s (163MB/s)(1024MiB/6573msec)
    slat (nsec): min=648, max=592020, avg=3806.49, stdev=4863.00
    clat (usec): min=60, max=3186, avg=396.92, stdev=131.05
     lat (usec): min=69, max=3189, avg=400.78, stdev=130.71
    clat percentiles (usec):
     |  1.00th=[  169],  5.00th=[  182], 10.00th=[  186], 20.00th=[  219],
     | 30.00th=[  400], 40.00th=[  433], 50.00th=[  441], 60.00th=[  449],
     | 70.00th=[  465], 80.00th=[  482], 90.00th=[  510], 95.00th=[  529],
     | 99.00th=[  701], 99.50th=[  783], 99.90th=[  898], 99.95th=[  988],
     | 99.99th=[ 1582]
   bw (  KiB/s): min=158840, max=160896, per=100.00%, avg=159660.92, stdev=760.89, samples=13
   iops        : min=39710, max=40224, avg=39915.23, stdev=190.22, samples=13
  lat (usec)   : 100=0.02%, 250=23.73%, 500=63.72%, 750=11.93%, 1000=0.55%
  lat (msec)   : 2=0.04%, 4=0.01%
  cpu          : usr=3.79%, sys=18.94%, ctx=216165, majf=0, minf=29
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.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.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=156MiB/s (163MB/s), 156MiB/s-156MiB/s (163MB/s-163MB/s), io=1024MiB (1074MB), run=6573-6573msec

Disk stats (read/write):
  sdf: ios=255243/2, merge=27/1, ticks=99895/3, in_queue=99898, util=98.52%

Besser, aber immer noch nicht ansatzweise an den 500MB/s sequentielles Lesen, was eigentilich zu erwarten wäre.

Da es sich nun um zwei unterschiedliche Dateisysteme und Schnittstellen handelt weiß ich nun wirklich nicht wo ich anfangen soll zu suchen. Die CPU ist nicht so stark belastet ( ~25% Auslastung) das dies einen Einfluss haben sollte und Arbeitsspeicher ist auch genügend vorhanden.
Hat jemand noch einen Hinweis für mich wo man auf Fehlersuche gehen könnte?

 

[Dunuin]

NVME SSD Pool (ZFS Mirror) :
1x SAMSUNG MZVLQ1T0HALB-00000
1x KINGSTON SNV2S1000G

Ein Mirror ist beim Schreiben so schnell wie die langsamste Disk. The Samsung ist gut, aber die Kingston ist sowohl mit TLC als auch mit super langsamen QLC NAND im Umlauf. Außerdem hat die Kingston keine Powerloss Protection, Sync Writes sind also generell schlecht, selbst wenn du eine Version mit TLC NAND erwischt hättest. Deine Kingston wird da also die Samsung SSD ausbremsen.

SATA SSD Pool (Ext4 formatiert) :
Verbatim Vi550 S3

Wieder Consumer SSD. Der Hersteller gibt auch keine Infos ob TLC oder QLC NAND verbaut wurde. Würde ich also keine gute Leistung erwarten. Gerade bei QLC NAND sind die SSDs gerne mal langsamer als HDDs im Durchsatz.

Nach Reviews und fremden Benchmarks kannst du bei Consumer SSDs übrigens nicht gehen. Die Hersteller bringen die SSD Modelle meist erst mit schnelleren NAND und Controllern auf den Markt, dann bekommen sie gute Benchmarks und Reviews und später werden dann die NAND chips und Controller gewechselt, die Modellnummer bleibt aber erhalten. Dann kaufen sich alle Leute das gleiche Modell wegen den guten Reviews, erhalten aber oft nur einen Bruchteil der Leistung, da zum Profit optimieren minderwertigere Hardware verbaut wird.
Wenn der Hersteller im Datenblatt nicht die NAND Technologie angibt und den verbauten Controller-Chip, dann sollte man lieber die Finger von der SSD lassen, weil dann sonst etwas in der SSD stecken kann.

 

[Byolock]

Das die Kinstgon bereits mit QLC gesichtet wurde, wusste ich nicht, die ist ja noch nicht sehr lange auf dem Markt. Da Kingston aber dafür berüchtigt ist Gute SSDs zu veröffentlichen, gute Reviews zu bekommen und dann Komponenten zu tauschen, habe ich die bei Erhalt mit HDTune Pro getestet und konnte TLC Speicher bestätigen. Ich hatte ehrlich gesagt bis jetzt die OEM Samsung eher für das schwächere Glied gehalten.
Bei der Verbatim hab ich leider nur ein Test der 512GB Version gefunden, in dem Fall konnte diese dauerhaft 500MB/s schreibend leisten also TLC, aber das heißt ja leider nichts in Bezug auf andere Modelle der selben Reihe.
Ich habe gerade noch eine Seagate Barracuda SSD gefunden. Diese werde ich morgen mal am PC und Proxmox Server Benchmarken und mal schauen ob es da auffälligkeiten gibt.

 

[Dunuin]

Bei ZFS auch nicht vergessen, dass da ZFS zum Teil Sync Writes benutzt. Du kannst also mit fio auch mal 4k Sync Writes testen. Dann hast du bei Virtualisierung auch noch erhöhe Write/Read Amplification. Sagen wir z.B. du machst 4K Sync Writes in einer Linxu VM mit ext4. Für jeden 4K Daten-Block der auf das ext4 DAteisystem geschrieben wird, kommen dann noch rund 12K oben drauf, da ext4 ja auch je Block noch Metadaten aktualisieren und ins Journal schreiben muss. Heißt wenn du da 4K an Daten auf das ext4 im Gast schreibst, dann sind das 16K die bei ZFS ankommen. ZFS muss ebenfalls wieder ins Journal schreiben, Metadaten schreiben, ... da sind die 16K schnell mal 32K. Ist daher also nicht verwunderlich, dass es in einer VM langsamer ist, als wenn man im Host direkt in ein Dataset schreibt, da man ja noch den Overhead von den verschachtelten Dateisystemen sowie unpassenden Blockgrößen hat.

Und was auch noch einen großen Unterschied macht ist, wie voll die SSDs sind. Ein ZFS Pool sollte z.B. nicht über 80% gefüllt werden, da er sonst langsam wird. Und selbst ohne ZFS wird die SSD je langsamer, desto voller sie ist. eine SSD die 95% gefüllt ist, ist üblicherweise unglaublich langsam, da sich kaum noch freie zusammenhängende Bereiche auf der SSD befinden und ständig SSD intern Daten herumgeschaufelt werden müssen. Auch haben SSDs keinen extra SLC NAND für ihren SLC-Cache, sondern sie beschreiben den TLC NAND im SLC Modus. Ist also ein TLC NAND chip bereits komplett mit deinen Daten voll, kann der auch nicht mehr als SLC-Cache benutzt werden. Der SLC-Cache schrumpft also auch mit der Zeit.

Und dann beim Benchmark am besten richtig große Datenmengen (z.B. 100GB) schreiben, wenn man nicht nur die Cache-Performance sehen will. Richtig übel sieht es bei den SSDs ja meist erst aus, wenn auch die SLC-Cache voll ist und dann die echte TLC/QLC Schreib-Performance zum Tragen kommt.

 

[RolandK]

> Verbatim Vi550 S3

das teil hab ich selbst auf win10 desktops mit ganz normaler workload schon abgrundtief schlecht performen sehen.

beim schreiben mit dd sieht man sehr schön , daß die performance ab 50gb writes drastisch einbricht - bei meiner 256gb vi550 von >300MB/s auf ca 40MB/s

ich wundere mich echt, warum es noch keine website gibt, die mal ein wenig mit den "performance lügen" der consumer ssd industrie aufräumt, denn die dinger werden in sachen schreib-performance gefühlt immer grottiger.

 

[Dunuin]

ich wundere mich echt, warum es noch keine website gibt, die mal ein wenig mit den "performance lügen" der consumer ssd industrie aufräumt, denn die dinger werden in sachen schreib-performance gefühlt immer grottiger.

Liegt halt einfach daran, dass der NAND auch immer kurzlebiger und langsamer wird. Also das Gegenteil was man sonst so von Microchips kennt, die ja mit jeder Generation schneller werden.
Wenn mich als Hersteller ein SLC, MLC, TLC und QLC NAND Chip das gleiche in der Produktion kostet, ich aber auf den QLC NAND 8 mal so viele Daten quetschen kann wie auf einen SLC NAND Chip, dann nehme ich natürlich den ollen QLC NAND Chip der mich nur 1/8 kostet. Oder halt QLC was mich nur die Häfte in der Produktion kostet wie TLC. Super Profitmaximierung, wenn man dem dummen Konsumenten eine olle QLC SSD für 90% des Preises einer gleich großen TLC SSD andreht, man selbst aber ordentlich an den Produktionskosten spart, auch wenn man dann ein super langsames Produkt abliefert. Das die SSD schneller kaputt geht ist ja sogar ein Bonus-Vorteil. Dann muss der Konsument halt öfter SSDs kaufen, was ja erwünscht ist und aus der Garantie ist man selbst raus, weil man die TBW halt entsprechend reduziert und die Garantie mit überschreiten der TBW verfällt. Und 99% der Konsumenten bekommen ja nicht mal mit, wie lahm die SSD ist und denken sie haben etwas ganz tolles gekauft, weil Caching abseits von Powerusern für eine kurze Zeit eine tolle Performance vorgaukelt.
Ähnliches bei der Spare-Area. Warum sollte ich 50% mehr für NAND ausgeben, um eine 1TB SSD mit 1,5TB NAND auf den Markt zu bringen, wenn dem Konsumenten eh nur die 1TB interessieren, die er auch nutzen darf und er nicht bereit ist für die unnutzbaren 0,5TB mehe hinzublättern, auch wenn es massiv die Performance und Langlebigkeit erhöhen würde. Dann lieber gleich nur 1TB verbauen und die als 960GB vermarkten.
Und wenn man ganz schlau ist, dann bringt man das SSD-Modell erst mit TLC-Bestückung auf den Markt, lässt sich gute Reviews und Benchmarks geben und dann ändert man die Bestückung auf QLC-NAND ohne die Produktnummer/Produktbezeichnung zu ändern oder den Preis zu senken. Dann kaufen die dummen Konsumenten unwissentlich die ollen QLC SSDs wegen den tollen Reviews/Benchmarks die inzwischen nicht mehr stimmen.

SSDs sind leider ein Markt mit denen sich kein Konsument auseinander setzen will. Bei CPU und Mainboard macht man sich schlau was eine gute Performance oder Preis-Leistung hat und von dem Geld was noch über ist steckt man halt die günstigste SSD in den Warenkorb ohne sich da groß mit zu beschäftigen.

Wenn man Konsumenten vergrauelt, dann ist das ziemlich egal. Die kaufen eh nur alle paar Jahre mal eine SSD und machen sich vorher nicht schlau und versuchen einen auch nicht zu verklagen weil das zu teuer wäre.
Einen Großabnehmer wie Google, Hetzner und Co, welche eher die Datacenter/Enterprise kaufen, möchte man aber nicht vergraulen. Die sollen ja regelmäßig fleißig nachkaufen, die haben Experten die sich vor dem Kauf schlau machen und eine große RMA oder Gerichtsprozess könnte echt teuer werden.

Ist dann aber nicht nur die Schuld der "bösen" Hersteller. Solange sich Konsumenten nur für die theoretische maximale Bandbreite über wenige Sekunden und den Preis-Pro-Gigabyte interessieren und nicht für die gemittelte Performance über einige TBs an IO oder den Preis-Pro-TBW wird sich da auch nichts ändern.
Und dazu müsste man sich halt erst einmal intensiver mit der Materie beschäftigen, um zu verstehen, warum eine hohe TBW wichtig ist und was der Unterschied zwischen Burst-Perfoemance und Langzeit-Performance ist.

Vielleicht kommt das ja irgendwann mal, wenn jeder Gbit-Internet daheim hat und der 200GB Download eines Steam-Spieles dann durch die tolle 5000MB/s PCIe 5.0 SSD gebremst wird, weil die in der Realität auf Dauer nur 40MB/s schafft.
Wer sich QLC SSDs kauft, der braucht sich auch garnicht erst mehr als eine 250Mbit-Internetleitung holen.