Najrýchlejší SSD disk na trhu

31.5.2016 22:58 | Přečteno: 2484× | poslední úprava: 2.6.2016 11:18

Cez víkend sa mi šťastnou zhodou náhod podarilo dostať k najrýchlejšieme SSD disku na trhu - Samsung NVMe SM951 512 GB. Rozhodol som sa spraviť menšiu recenziu a nejaké tie testy. Testovacia zostava je samozrejme moje nové PC.

Predstavenie

Samsung NVMe SM951 512 GB pre M.2 socket - momentálne asi najrýchlejší SSD disk - minimálne na slovenskom trhu. SSD používa 16 nm MLC čipy Samsung so životnosťou až 500 TBW (Tera Bytes Written). Jeho parametre sú nasledovné.

Čítanie: až 2150 MB/s
Zápis: až 1260 MB/s
Náhodné čítanie: až 300 000 IOPS
Náhodný zápis: až 100 000 IOPS

Inštalácia a identifikácia pod Linuxom

Po prvom kontakte a HW inštalácii SSD do jedného z dvoch M.2 slotov dosky, som sa rozhodol nainštalovať na SSD linux - konkrétne Debian 8. Inštalácia prekvapivo SSD našla aj správne identifikovala - všetko išlo ako malo až do chvíle inštalácie zavádzača. Tam som narazil na chybu. Skúsil som GRUB, LILO no bez výsledku. Nasledovalo googlovanie a zistil som nasledovné. Dvakrát som skusil daný návod, no neuspéšne a kedže už bola nedeľa neskoro večer ďalšie pokusy s Debianom 8čkou som už neskúšal a stiahol som inštalačku Debian 9 Scretch/Sid a tam už grub fungoval ako mal. Takže som v tú chvíľu mal už funkčný systém na novom SSD. Prehodil som z iného SSD disku nastavenia (/etc, domáci adresár a zoznam balíkov a spustil inštaláciu všetkého potrebného).

Takže pod jadrom 4.5.0-2-amd64 z Debianu 9 sa SSD disk hlási ako:

0d:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)

Testovanie

hdparm

sudo hdparm -Tt /dev/nvme0n1

/dev/nvme0n1:
 Timing cached reads:   34580 MB in  2.00 seconds = 17313.68 MB/sec
 Timing buffered disk reads: 5180 MB in  3.00 seconds = 1726.18 MB/sec

gnome-disks



fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=256M --numjobs=8 --runtime=60 --group_reporting

randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
...
fio-2.10
Starting 8 processes
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
randwrite: Laying out IO file(s) (1 file(s) / 256MB)
Jobs: 7 (f=7): [w(7),_(1)] [100.0% done] [0KB/424.6MB/0KB /s] [0/109K/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=8): err= 0: pid=7642: Tue May 31 22:32:25 2016
  write: io=2048.0MB, bw=380677KB/s, iops=95169, runt=  5509msec
    slat (usec): min=5, max=974596, avg=80.60, stdev=7766.20
    clat (usec): min=0, max=308, avg= 0.29, stdev= 0.80
     lat (usec): min=5, max=974598, avg=80.97, stdev=7766.22
    clat percentiles (usec):
     |  1.00th=[    0],  5.00th=[    0], 10.00th=[    0], 20.00th=[    0],
     | 30.00th=[    0], 40.00th=[    0], 50.00th=[    0], 60.00th=[    0],
     | 70.00th=[    0], 80.00th=[    1], 90.00th=[    1], 95.00th=[    1],
     | 99.00th=[    1], 99.50th=[    2], 99.90th=[    2], 99.95th=[    3],
     | 99.99th=[    9]
    bw (KB  /s): min=60856, max=126120, per=25.17%, avg=95831.54, stdev=15978.61
    lat (usec) : 2=99.33%, 4=0.63%, 10=0.03%, 20=0.01%, 50=0.01%
    lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%
  cpu          : usr=0.93%, sys=14.69%, ctx=159383, majf=0, minf=81
  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    : total=r=0/w=524288/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: io=2048.0MB, aggrb=380677KB/s, minb=380677KB/s, maxb=380677KB/s, mint=5509msec, maxt=5509msec

fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=8 --runtime=240 --group_reporting

randread: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=16
...
fio-2.10
Starting 8 processes
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
randread: Laying out IO file(s) (1 file(s) / 512MB)
Jobs: 8 (f=4): [f(2),r(3),f(2),r(1)] [100.0% done] [372.3MB/0KB/0KB /s] [95.3K/0/0 iops] [eta 00m:00s]
randread: (groupid=0, jobs=8): err= 0: pid=7811: Tue May 31 22:34:45 2016
  read : io=4096.0MB, bw=380850KB/s, iops=95212, runt= 11013msec
    slat (usec): min=65, max=4418, avg=82.84, stdev=18.83
    clat (usec): min=0, max=9097, avg=1259.17, stdev=76.93
     lat (usec): min=69, max=9205, avg=1342.18, stdev=80.50
    clat percentiles (usec):
     |  1.00th=[ 1160],  5.00th=[ 1192], 10.00th=[ 1208], 20.00th=[ 1224],
     | 30.00th=[ 1240], 40.00th=[ 1240], 50.00th=[ 1256], 60.00th=[ 1272],
     | 70.00th=[ 1272], 80.00th=[ 1288], 90.00th=[ 1320], 95.00th=[ 1336],
     | 99.00th=[ 1384], 99.50th=[ 1416], 99.90th=[ 1544], 99.95th=[ 2192],
     | 99.99th=[ 4832]
    bw (KB  /s): min=46920, max=48152, per=12.51%, avg=47651.81, stdev=182.73
    lat (usec) : 2=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
    lat (usec) : 1000=0.01%
    lat (msec) : 2=99.93%, 4=0.04%, 10=0.02%
  cpu          : usr=1.53%, sys=8.68%, ctx=1048955, majf=0, minf=189
  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    : total=r=1048576/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: io=4096.0MB, aggrb=380850KB/s, minb=380850KB/s, maxb=380850KB/s, mint=11013msec, maxt=11013msec

dd if=/dev/zero of=tempfile bs=1M count=20480 conv=fdatasync,notrunc status=progress && sync

19100860416 bytes (19 GB, 18 GiB) copied, 5.00009 s, 3.8 GB/s 
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 6.35217 s, 3.4 GB/s

time rm tempfile

real	0m1.674s
user	0m0.008s
sys	0m1.644s

time tar xf ./linux-4.6.tar.xz

real	0m6.314s
user	0m5.468s
sys	0m1.364s

a zo srandy: time pxz -d -e linux-4.6.tar.xz

real	0m5.257s
user	0m5.052s
sys	0m0.200s

cd linux-4.6 && make clean && make defconfig && time make -j 8

real	1m45.311s
user	11m57.640s
sys	0m33.292s

dbench -D /home/test* -t 180 150

Operation      Count    AvgLat    MaxLat
 ----------------------------------------
 NTCreateX    4242331     0.798   135.693
 Close        3118398     0.001     3.406
 Rename        179743    10.691   119.931
 Unlink        854312     8.990   162.852
 Qpathinfo    3853880     0.024    91.208
 Qfileinfo     672865     0.001     1.694
 Qfsinfo       702956     0.002     2.442
 Sfileinfo     346278     0.220    11.717
 Find         1486474     0.091    26.967
 WriteX       2097999     0.095   161.195
 ReadX        6653382     0.002     7.880
 LockX          13830     0.002     2.576
 UnlockX        13830     0.001     0.669
 Flush         296534    45.448   276.845

Throughput 732.755 MB/sec  150 clients  150 procs  max_latency=276.847 ms

Ak by vás samozrejme zaujímali aj iné testy tak to napíšte do diskusie. Priebežne budem dopĺňať...        

Obrázky

Komentáře

[Bystroushaak]

so životnosťou až 500 TBW (Total Bytes Written)

Ti tam vypadla jednotka, pochybuju, že by to bylo jen 500 bajtů.

[GothiqueNoir]

Vďaka. Opravujem.

[Mrkva]

Jeste umazat to jedno r, kdyz uz jsme hnidopisi.

[GothiqueNoir]

To tak keď to v noci opravujem... =]

[dbguru]

Pozor pri nasazeni s nejnovejsi Postgresql

ktera podporuje vice prozesoru. Implementace je bohuzel tak, ze ty rychle odpovedi prepisi db-cache a dochazi k uplne nesmyslnym vysledkum. Vyvojari patrne pocitali s beznou latenci byt i rychlych disku a beznych SSD, ale harddisk autora se blizi k hranic, kdy to muze byt kriticke. Pro jistotu prepnou do single modu.

[Tomáš Bžatek]

A co kdyz ma clovek databazi na tmpfs? (smysl takoveho reseni ted nechme stranou)

[Ladislav Jacek]

Pamäť RAM je najrýchlejšia...

[Max]

To jako fakt? Protože začínají být celkem běžná SSD pole pro databáze. Zrovna teď něco takového budeme nasazovat, 2TB pole ze 12ks 400GB SSD pro Oracle RAC.
Zdar Max

[MP]

SATA? NVMe? Jak je pak poreseno samotne pole?

[MaloSaKradne]

Uz si videl dosku s 12 x m.2/PCIe slotami ? :D

[MP]

Ono to nemusi byt zavisle na poctu portu na desce...viz https://www.supermicro.com/products/nfo/NVMe.cfm

[MaloSaKradne]

Fuha - pekne... cenu celeho riesenia si radsej ani nepredstavujem...

[MP]

10port NVMe 1U je cca 60k bez DPH, bez cpu/ram/atd. Neni to tak drahe na ten vykon, co to poskytne

[MaloSaKradne]

Takze kompletna cena s SSD, CPU a RAM vyjde kolko ?

[MP]

Co mam zkalkulovano, tak zhruba 100k (myslim, ze bez DPH) s tim, ze v tom bude 2x nektery ze zakladnejsich Xeonu a 8-32GB RAM. Dalsich 100k ty 512GB Samsungy, kdyby byly v SSF (U.2).

[MaloSaKradne]

Hmmm to mi sef neschvali ani nahodou :D

[Bedňa]

Na Slovensku je to necelých 7000 táckov, to len v Čechách je to tak drahé

[MaloSaKradne]

Jaaaj, to mozem skusit ako argument

[ekonom (inženýr!)]

ale EUR!!! takto by kdekdo mohl říct, že vidělává víc než třeba Němci, Američané... například já jako vysokoškolsky vzdělaný člověk vidělávám 18 tisíc KORUN čístého měsíčně, to je něco přes 200 tis. KORUN ročně a taky netvrdím že vydělávám víc než američané když většina z nich těch 200 tis. DOLARů mít nebude, ale ovšem pozor, dolar má dvacetinásobnou hodnotu než naše milovaná koruna Česká a tedy to až tak slavné s těmi našimi příjmy taky není a je hloupost si myslet, že kdybychom zavedli EURO, tak zchudneme, ono bychom pak sice dostávali třeba 3éx mín číselně ale i ceny by šly 30krát dolů a tak dál... no zkrátka si DOPLŇTE VZDĚLÁNÍ než začnete plácat takové hlouposti, svět není jen o počítačích a kalkulačkách

[Bedňa]

Myslel som to ako srandu a myslím si že vyšie píšuci užívateľ "MaloSaKradne" to pochopil ako som to písal.

[Bystroushaak]

>>> butt.status
'hurt'

[Václav "Darm" Novák]

Člověk co napíše "vidělávám" doporučuje doplnit si vzdělání, super :)

Ještě by to chtělo doplnit si smysl pro humor.

[Pavel 'TIGER' Růžička]

Inu titul od blbosti nechrání.

[Bystroushaak]

To je očividný trolling, celý ten post, ne?

[Max]

Netapp + FC.
Zdar Max

[xsubway]

To by chtělo důkaz místo slibů...

[MaloSaKradne]

Niečo tu...

[Michal Kubeček]

To je ale něco úplně jiného, než tvrdil "dbguru" výše.

[Dik777]

Článek se týká clonu Mysql a je z roku 2009, to nezní moc směroplatně Máňo Dik777

[Dik777]

To je ale nesmysl. Znám pár PG instalací na SSD a no problema... Dik777

[podlesh]

Jak dlouho běží na PG 9.6?

[Dik777]

Sám sis odpověděl níže. 9.6 Beta1 nikdo rozumný do ostrého provozu nedá. Dik777

[Filip Jirsák]

Jenže právě o 9.6 beta1 psal Dbguru, protože psal o „nejnovější PostgreSQL s podporou více procesorů“.

[Dik777]

Ok, moje chyba, tak to jsem přehlédl.... Dik777

[podlesh]

Pozor pri nasazeni s nejnovejsi Postgresql

ktera podporuje vice prozesoru. Implementace je bohuzel tak, ze ty rychle odpovedi prepisi db-cache a dochazi k uplne nesmyslnym vysledkum. Vyvojari patrne pocitali s beznou latenci byt i rychlych disku a beznych SSD, ale harddisk autora se blizi k hranic, kdy to muze byt kriticke. Pro jistotu prepnou do single modu.

To je zajímavá informace... nicméně lze předpokládat že každý kdo bude nasazovat db engine ve verzi Beta 1 si buď již pozor dává a velký, nebo ho takové drobnosti nezajímají

[MaloSaKradne]

ale ved to by sa muselo prejavit aj pri db-cache resp. db umiestnenej priamo na tmpfs a teda v RAM, nie ?

[Adam]

Zajímalo by mně pouití 2 x Samsung NVMe SM951 512 GB v softwarovém RAID0 pod Linuxem ... Dosáhlo by to 4GBps ?

[MP]

Taky by me zajimalo. Jedna firma pri nastrelu navrhu storage me informovala, ze z jejich zkusenosti maji NVMe nad SW raidem tak 1/2 vykonnost. Nemuzu to bohuzel zatim stale overit, storage se porad nerealizovalo.

[and_i]

Mi davaji zhruba totez co jedna bez RAIDU, coz pro dany ucel vyhovuje.

[Adam]

hod tu co ti ukazuje hdparm -Tt nad raid0

[and_i]

jedna z karet:

Timing cached reads: 24500 MB in 2.00 seconds = 12264.85 MB/sec

Timing buffered disk reads: 2682 MB in 3.00 seconds = 893.48 MB/sec

raid0:

Timing cached reads: 24788 MB in 2.00 seconds = 12409.21 MB/sec

Timing buffered disk reads: 5488 MB in 3.00 seconds = 1829.28 MB/sec

Nova davala prez 1500 MB/sec i karta sama, fstrim vraci 0 bytes trimmed, hmm...

[Adam]

Autorovi blogpostu dava jedno NVMe ako tvoje dve v RAID0 :D

[and_i]

Vsak mi nove davalo tez dvojnasobek...

A propo jadro 2.6.32 a pod., s tim nic nenadelam...

[MaloSaKradne]

2.6.32 nema podporu NVMe

[Michal Kubeček]

Není 2.6.32 jako 2.6.32…

[and_i]

Diky, ano neni to samozrejme vanilka, ale distribucni kernel.

Srovnani miry podpory NVMe v 2.6.32 s backportovanou funkcnosti a autorove 4.5.0-2 pripadne prenecham ostatnim.

Uvedene hodnoty pro muj ucel dostacuji, io rezie typicke ulohy klesla na zvladnutelnou miru, neni to radove nejuzsi hrdlo.

[and_i]

Rychlejsi by mohlo byt toto http://www8.hp.com/us/en/workstations/z-turbo-drive-g3.html

[HW guru]

Disk ma zivotnost 500TBW.
- cca 20 GB vytvori za cca 5 sekúnd z /dev/zero
- neberme do uvahy cca 5GB ako reziu systemu
- 1000 cylov po 500 GB moze poskodit pamatove bunky SSD disku


cize:

for i in {1..1000}; do dd if=/dev/zero of=tempfile bs=1M count=512 000 conv=fdatasync,notrunc status=progress && sync && rm -f tempfile ; done

- za 128 sekúnd vytvorí 512GB súbor a za 35 hodín vytvorí takýto súbory 1000 krát

Cize staci 35 hodín neustáleho zapisovanie na znicenie nejakej bunky SSD ?

[MP]

1] merit pomoci DD je spatne - nebere se tam v uvahu cache, navic pokud ten disk ma cca 1.2GBps zapis, nemuze mit 4GBps zapis pres DD --> 20GB vytvori minimalne za 16.6s, takze potreba priklad prepocitat

2] zkuste si spocitat to same i pro rotacni disk, jak dlouho mu takova operace bude trvat (iopsy zanedbejme)

3] pri generovani 500GB/cykl urcite nepouzijete 400GB disky libovolneho formatu/rozhrani

[MaloSaKradne]

Ad 1]

19100860416 bytes (19 GB, 18 GiB) copied, 5.00009 s, 3.8 GB/s 
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 6.35217 s, 3.4 GB/s

[chrono]

Nie je časť tých dát stále len v RAM?

[MaloSaKradne]

dd if=/dev/zero of=tempfile bs=1M count=20480 conv=fdatasync,notrunc status=progress && sync

RAM je tusim 8GB a je tam sync, tak neviem...

[HW guru]

conv=fdatasync

This tells dd to require a complete “sync” once, right before it exits. So it commits the whole 256 MB of data, then tells the operating system: “OK, now ensure this is completely on disk”, only then measures the total time it took to do all that and calculates the benchmark result.

[MP]

Takze vyrobce uvadi 1.2GBps, na http://ssd.userbenchmark.com/SpeedTest/30300/NVMe-SAMSUNG-MZVKV512 je prumer/max 1.3/1.5GBps a dd bude ukazovat 3k+GBps? To mereni pres dd teda fakt nesedi.

[Josef Kufner]

Pokud je disk prázdný a nemusí kopírovat přepisované bloky, tak by ten dvojnásobek mohl být teoreticky možný. Vypni trim, naplň disk a zkus to znovu.