Milyen SSD-t szerverbe

Szerverek

Sziasztok!

 

Van egy régi Dell PowerEdge T410 szerverünk HDD-vel. Gondolkozunk az SSD upgraden. A szerveren van pár kisebb nagyobb forgalmú weboldal, több 10 GB MySQL és több 10 GB PostgreSQL adatbázis.  Milyen SSD-t ajánlanátok bele és hányat? PCI-E alapú SSD-k menni fognak,? pl ez: 

 

https://ssd-meghajto.arukereso.hu/samsung/970-pro-1tb-m-2-pcie-mz-v7p1t0bw-p408169109/#termek-leiras

 

A hardver mostanában nagyon nem az én világom, de valószínűleg nekem kell ezt megoldanom mind hardveresen mind szoftveresen ( a rendszer költöztetését is).

 

Köszönöm.

A fenét, megint megszopattatok, ez egy 3 éves topik, és csak most veszem észre, hogy potyára írogatok bármit is. Tényleg zárni kéne ezeket már.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ja, ezt jobb lenne elkerülni. Először egy elég hosszú hsz-t írtam, majdnem 4 sor volt az NVMe-támogatásról, az már Jókai kisregény, de aztán veszem észre, hogy 2019-es a dátum, és már valószínűleg a gépet is kidobták, vagy megy még, de az SSD-t rég megvették bele.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( agostonl | 2019. 10. 28., h – 16:34 )

Az én kérdésem az lenne, hogy milyen rendszer, van-e virtualizálás, milyen tipusú partíciók?

Amúgy, ha jól látom, ebbe sima sata csatis SSD mehet csak.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"

"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Nézd meg a Samsung PM883 vagy SM883-as cuccait, SATA-s enterprise cuccok. Hogy a konkrét DELL gépben, illetve az abban lévő vezérlővel hogy megy az megint más kérdés. Esetleg érdemes lehet a serverelite.hu -soknál érdeklődnöd, mert lehet vele tapasztalatuk. Ha már a géphez hozzányúltok akkor ehhez a RAM és CPU bővítés is filléres lehet, illetve ha már SSD, akkor szerintem mindenképp. (Példul ha E55xx széria, akkor az E56xx tetejével elég jót lehet robbantani, de az X56xx -ekkel akár két E55xx is kiváltható adott esetben.)

Köszi az értékes infót! Kb. egy bő éve a memóriát felbővítettük 64 GB-ra, de itt van még bespájzolva 64GB, csak még egy procit kellene szerezni, jelenleg E5645 van benne, de amikor a memóriát bővítettük nem találtunk eladót, aztán el is felejtődött a projekt. 

<befőttesüveg>
meggy
</befőttesüveg>

( ladanyid | 2019. 10. 29., k – 15:39 )

Nekem ment már levesbe egy Samsung PM883. Egyik reggel soha többé nem látta a szerver és más gép se. 860PRO-t rakok azóta szerverbe ha kell és nincs pénz gyártói supportált SSD-re. Azokkal még nem volt gondom. Ha RAID1-be mennek akkor párjának EVO-t veszek. Azokkal se volt még gondom.

( egeresz | 2019. 10. 29., k – 22:03 )

- swappet kapcsold ki (de legalábbis swappines=1) sok a memória, a linux relatíve rosszul swappel, inkább ne swappeljen. Ha nem fér be, akkor kell neki még ram. Sehogy se jó, ha swappel. (hard page out)

- a rendszer (kernel, libek, /usr) maradjon HDD-n. Ugyanis, a boot mindegy hogy 30 sec vagy 42 sec. Amit egy szerver normál üzemben használ prgramok, azoknak úgy is a memóriában a helye (teljes nevén named page pool), ezen dolgok SSD-re paokolása nem segít menet közben.

- biztos a diszk IO a kevés? 'sar -d -p 3' nézegesd erős terhelésnél. Utolsó oszlop 100% körül van, lehet kezdeni gondolkodni; a legfontosabb oszlop a aqu-sz (hány kérés várakozik egyszerre arra a diszkre?) ez nem árt, ha csúcsterhelésnél is 1 alatt/körül marad (30 diszkes raidnál azért megengedhető aqu-sz=30 is)

- nem a cpu a kevés? `uptime` kiírja a load average-t, 'top' meg kiírja, hogy hány 'R' (cpu-ra vár) és hány 'D' (diszkre vagy névfeloldásra vár) processz van. ezek összege a load.

Naszóval, ha oda jutottál, hogy tényleg a diszk IO a kevés, akkor.. vegyél pcie intel optane-t. És csak a DB-ket rakd oda. És ha valamely webapp használ átmeneti file-t, akkor azt rakd tmpfs-re. Olyan érzés lesz, mintha felszállnál.

Mennyi a sebesége egy optane-nak szinkron írásnál ? (VM-ek alapértelmezetten szinkron írnak).

 fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1

a fenti méréssel az "asztali " Samsung-ok 4k-s szinkron írásnál tudnak kb 15-20 MB/sec-et,(850, 860  EVO, stb, de 970 EVO pl csak 5 Mb/sec, hiába NVMe),  INTEl DC-k kb 70 MB/sec (pl. s3700)  

Lemérné valaki , hogy egy ilyen 10 μSec-es SSD mit tud 4k-s szinkron írásnál? 

https://blog.claryel.hu

nem véletlenül írtam az optane-t, hanem mert 4k/64k, 1..32 szál, O_SYNC vagy sem, random vagy seq írásnál mindenhogy egyenletesen kitolta a ... sajnos nem emlékszem a pontos értékre, csak arra, hogy sehol nem láttam renyhülést. Azóta is szépen teljesít egy 24 diszkes ZFS intent log-ként, és nem az a szűk keresztmetszet (soha).

Mellesleg egy Xeon E5620 -ös gépen fut, az pont ugyan az a korosztály, mint a Tisztelt Topicnyitó E5645 cpu-ja.

A tesztelt optane: INTEL 280GB 900P Series PCI Express HHHL/PCI Express SSDPED1D280GASX

ez szar meres, mert iodepth=16, meg csak 100 mega.

itt egy jo meres:

root@s19:~# fio --filename=/dev/nvme0n1 --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.13
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=217MiB/s][w=55.5k IOPS][eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=2689150: Fri Nov  1 22:07:09 2019
  write: IOPS=55.6k, BW=217MiB/s (228MB/s)(12.7GiB/60001msec); 0 zone resets
    clat (usec): min=13, max=1749, avg=17.23, stdev= 3.80
     lat (usec): min=13, max=1749, avg=17.33, stdev= 3.80
    clat percentiles (nsec):
     |  1.00th=[14784],  5.00th=[15296], 10.00th=[15424], 20.00th=[15680],
     | 30.00th=[16064], 40.00th=[16192], 50.00th=[16768], 60.00th=[17280],
     | 70.00th=[17536], 80.00th=[17792], 90.00th=[18048], 95.00th=[18560],
     | 99.00th=[41216], 99.50th=[41728], 99.90th=[45824], 99.95th=[52992],
     | 99.99th=[84480]
   bw (  KiB/s): min=219328, max=225880, per=100.00%, avg=222454.19, stdev=1340.55, samples=119
   iops        : min=54832, max=56470, avg=55613.56, stdev=335.15, samples=119
  lat (usec)   : 20=97.35%, 50=2.60%, 100=0.05%, 250=0.01%
  lat (msec)   : 2=0.01%
  cpu          : usr=10.32%, sys=27.54%, ctx=3336824, majf=0, minf=12
  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=0,3336799,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):
  WRITE: bw=217MiB/s (228MB/s), 217MiB/s-217MiB/s (228MB/s-228MB/s), io=12.7GiB (13.7GB), run=60001-60001msec

Disk stats (read/write):
  nvme0n1: ios=44/3331054, merge=0/0, ticks=1/43653, in_queue=0, util=99.89%

root@s19:~# nvme list | grep nvme0
/dev/nvme0n1     PHMB7363005X480DGN   INTEL SSDPED1D480GA                      1         480.10  GB / 480.10  GB    512   B +  0 B   E2010325
root@s19:~#

Köszi a mérést, az iodepht=1 a korrekt nem a 16, csak akkor most azt látnám , hogy Samsung  3 MB/sec ,Optane 230 MB/sec.

Nekem meg Samsungjaim vannak.

Szerintem a szinkron írás sebessége nem függhet a tesztfile méretétől, én direct=1 helyett  --fsync=1 et használtam, és mindegy volt a fájlméret.

https://blog.claryel.hu

marmint?

azert tud ennyit, mert ha directben irsz, akkor megkered a driveot, hogy volatilis cachebe ne irjon. mivel a samsungban nincs power loss protection (PLP), igy ha igy kered az irast, o kenytelen kozvetlen a nandra irni, ami lassu. (foleg 4k-ban, hiszen a nand csippeket >4kban cimzik, ugyhogy kapsz szep read-modify-write ciklusokat...)

a legtobb "sima" enterprise driveon (ami nem az optane), ott van rajta memoria, es van rajta eleg kondi, hogy ha elmegy az aram, akkor ki tudja flusholni a teljes RAM-ot NAND-ra, mielott leall, igy itt nem gond az, ha a 4k-s irast elobb a driveon levo memoriaba irja, amit majd utana idonkent a GC kiflushol.

a high-end enterprise driveokon (mint pl az IBM FCM, vagy egyes gyartok proprietary drivejai) tobb hierarchia is van, RAM, SLC es QLC egymas mellett.

az optane teljesen mas ebbol a szemszogbol, ugyanis nand helyett phase change memory van rajta (amigy az IBM Research fejlesztett ki amugy elsonek, pont Zurichben :P), ami annyit tesz, hogy olyan fizikai anyagbol van, aminek valtozik egy fizikai allapota (ellenallas altalaban) valamilyen behatasra (altalaban valtozo feszultseg), igy a feszultsegvaltozassal tudod programozni 0/1/2/..-be, majd utana eleg megmerned az ellenallasat, hogy megkapd a bitet.

 

tehat PLP-s enterprise driveokon illetve optanen nagyon gyors lesz minden, ami meg nem ez, ott meg nagyon lassu, ha direktben irsz. a kerdes mar csak az, hogy fontos-e a direkt iras. enterprise kornyezetben fontos az end-to-end integrity, ugyhogy igen, illetve a kulonbozo adatbazisok (Db2, Oracle) szeret sync/direct irni.

Igen, kössz, a PLP megléte esetén a dram kessbe történő szupergyors írást azt így már akkor értem. Ahol nincs PLP, ott a dram cache nem is ÉRDEMES használni írásra csak olvasásra, mint amikor a HDD write cache-t kikapcsoltuk szerveren? Ebben a fenti tesztben a szinkron írás direktben a flashre írat, a dram kesst szándékosan kihagyva?

Illetve akkor az nem világos nekem, egy konzumer ssd pl. samsung evo 860 / 870 csak a dram kess telítésig gyors? Utána leesik annak a sebessége is ilyen 5-10 MB/sec-re?

PLP nelkuli eszkozzel ha van barmifele aramkimaradas elleni vedelmed, akkor kicsi az eselye, h beszivod. a legtobb laptop pl ilyen, ott ez nem fordul elo altalaban.

igen, a fenti teszt kihagyta az eszkozon levo dram cachet.

igen, ez hosszabb teszteken szepen latszik, hogy az elso par perc nagyon gyors, aztan leesik - ha nem 4k a blokkmeret, hanem mondjuk mondjuk 128k akkor is nagyon szepen latszik a grafikonon, de akkor messze nem ilyen drasztikus az eses. de a 2GB cachet kozben folyamatosan pakolja ki a kontroller a NANDra, tehat nem konkretan az telik meg.

 

a szakmai velemenyem az, hogy annyira olcso a PLP-s datacenter NVMe (pl a Samsung 9A3), hogy nem erdemes nem ilyet venni ma mar.

A történet teljességéhez azért hozzátartozik, hogy az iodepth=1 egy nagyon speciális használati eset. Ez gyakorlatilag tisztán a latency-t méri, nem az áteresztőképességet. Nyilván, ha meg kell mutatni, hogy miben jobb az Optane egy NAND alapú SSD-nél, akkor ezt érdemes elővenni.

A legtöbb gyakorlati alkalmazásnál (főleg szerveren) egyidejűleg több művelet is lesz folyamatban és a NAND-alapú SSD-k elég jól tudják kezelni a párhuzamosan zajló műveleteket. A latency akkor számít, ha minden írásművelet után azonnal barrier van (valami patologikus journal használat és/vagy nagyon buta tranzakciókezelés miatt). Nem állítom, hogy nem fordulhat elő ilyen DB-nél, de nem ez a tipikus. Szarul megírt alkalmazás persze bármilyen hardvert és DB engine-t képes kétvállra fektetni :)

"Illetve akkor az nem világos nekem, egy konzumer ssd pl. samsung evo 860 / 870 csak a dram kess telítésig gyors? Utána leesik annak a sebessége is ilyen 5-10 MB/sec-re?"

Nem, a DRAM cache valójában nagyon pici az SSD méretéhez képest, és írásnál user adat pufferelésre nem is nagyon merik használni a PLP nélküli drive-okban. Pár perc nagyon intenzív random write után a desktop SSD-k teljesítmény visszaesése két fő okra vezethető vissza (benchmark grafikonon általában két külön töréspont látszik):

- Az SLC cache megtelése. Az üres flash-t gyorsan felzabálja, ha cellánként 1 bites módban írják, ezért a kontroller idővel el kell kezdje az SLC-s blokkokat TLC vagy QLC-re összepakolni. Ez jellemzően az SSD üres kapacitásának negyede-harmadánál üt be.

- A blokk-fragmentáció miatti garbage collection. Ez jellemzően nagyon hamar, az első pártíz GB írása után beüt. A flash erase blokkja sokkal nagyobb (16+MB), mint a logikai blokk (512byte vagy 4kB), fizikailag felülírni flash-t nem lehet, csak erase blokkot egyben törölni és az egészet újraírni. De az SSD vezérlőnek úgy kell tennie a host fele, mintha kis blokkokat tudna felülírni. Ilyenkor a kontroller annyit tud tenni, hogy a régi adatot meghagyja az eredeti helyen (mert óriási blokkot kéne törölni és újraírni). Egy új helyre (tipkusan valami journal-szerű sorfolytonos naplóba) bekerül a felülírt a blokknak frissebb tartalma. Ehhez extra hely kell és ez idővel kifogy. Ilyenkor a kontroller kénytelen garbage collectolni, a régen megírt, már sok elavult adatot tartalmazó erase blokkot törölni és a naplóból friss adatokkal berendezve újraírni. A garbage collection stratégia a desktop és az enterprise SSD-k között nagyon eltérő. A desktop SSD-k végletekig halogatják a garbage collection-t, hogy a csúcsteljesítmény szép nagy szám legyen. Viszont ha már muszáj, akkor nagyon lelassulnak. A szerver SSD-k meg igyekeznek transzparensen folyamatosan csinálni, így a csúcsteljesítményük kisebb lesz, de legalább azt konstans tudják tartani akármennyi ideig.

Régóta vágyok én, az androidok mezonkincsére már!

A legtöbb gyakorlati alkalmazásnál (főleg szerveren) egyidejűleg több művelet is lesz folyamatban és a NAND-alapú SSD-k elég jól tudják kezelni a párhuzamosan zajló műveleteket. A latency akkor számít, ha minden írásművelet után azonnal barrier van (valami patologikus journal használat és/vagy nagyon buta tranzakciókezelés miatt). Nem állítom, hogy nem fordulhat elő ilyen DB-nél, de nem ez a tipikus. Szarul megírt alkalmazás persze bármilyen hardvert és DB engine-t képes kétvállra fektetni :)

WAL ala tipikusan meg mindig ilyeneket raknak elosztott rendszerekben is, illetve lattam en mar optanebol cachet is. nem kell mindig szar appokra gyanakodni (bar van boven..)

Nem állítom, hogy nincs olyan valós alkalmazás, ahol tényleges elvi okokból ne lehetne szükség rá. De azt igen, hogy a legtöbb embernek előbb jön szembe egy szarul megírt app, aminek a jóisten hardvere sem elég :)

(Félig off: Épp most kuncogtam egyet GKH 128-magos szerverén... Ó, hogy mi már mennyi ideje használunk 128 magos gépeket... egy szarul megírt, skálázhatatlan appszerver alá. Bár épp nemrég raktam vissza őket 64 magos VM-ekre miután rámutattam, hogy az előző devops-os bandának nem tűnt fel, hogy windows-on, processor group támogatás nélkül sosem fog egy folyamat 64 magnál többet kihasználni.)

Régóta vágyok én, az androidok mezonkincsére már!

A történet teljességéhez azért hozzátartozik, hogy az iodepth=1 egy nagyon speciális használati eset.

Majd kijavítanak, ha rosszul gondolom, szerintem nem speciális eset a szinkron írás. Az iodepht=1 (és az fsync=1) az a szinkron írás. fio-nál azért adják meg, ha netán aszinkron motorral tesztelsz (nem adtad meg a motort) , akkor kényszerítsd szinkron írásra , Szinkron motorral mindegy hogy iodepth=1 vagy 100. Nincs sorban állás, csak az aszinkron írásnál. Például ZFS ZIL log ssd ilyen terhelést kap. Proxmox-ban is választhatod VM enként a szinkron írást, a biztonság megnő,  a teljesítmény borzalmas lesz. Ide kellene az optane, de legalább plp-s ssd. 

https://blog.claryel.hu

Ok, de én ezt mérem ha libaio  motor helyett ioengine=sync motort adok meg:

Model Family:     Intel 520 Series SSDs
Device Model:     INTEL SSDSC2CW120A3
 

root@srv01:/# fio --name=ssdtest --filename=testfile1 --size=1000M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 --ioengine=sync |grep write:
  write: IOPS=508, BW=2034KiB/s (2083kB/s)(1000MiB/503489msec)
root@srv01:/#
root@srv01:/# fio --name=ssdtest --filename=testfile1 --size=1000M --bs=4k --iodepth=512  --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 --ioengine=sync |grep write:
  write: IOPS=521, BW=2085KiB/s (2135kB/s)(1000MiB/491161msec)
root@srv01:/#
 

 

Szépen hozza a nem PLP-s ssd-k 2MB/sec sebességét  mindkét esetben.

https://blog.claryel.hu

wow de kemény teszt.

öregecske dellecske, benne intel ssd: 

write: IOPS=2186, BW=8747KiB/s (8957kB/s)(1000MiB/117073msec); 0 zone resets

fogok a dell-be keríteni nvme samsungot, azt is megmérem.

(mondjuk ez egy zfs raid1 igazából, nem tudom ez mennyit számít)

Gábriel Ákos

Nyilván az OP problémafelvetése alapján (1db régi szerverbe SSD) én nem az ilyen large-scale storage infrákra asszociáltam, így a "speciálisat" értsd úgy, hogy a ZFS ZIL szinkron üzemmódban már nem hétköznapi eset. Egy MySQL alá, nem feltétlen az iodepth=1 lesz a reprezentatív mérési eredmény. Pláne, ha több független DB instance fut ugyanazon a vason, akkor ha külön-külön éppen szinkronban is írnak, együttesen mégis magasabb queue depth-et fognak okozni.

Régóta vágyok én, az androidok mezonkincsére már!

Pláne, ha több független DB instance fut ugyanazon a vason, akkor ha külön-külön éppen szinkronban is írnak, együttesen mégis magasabb queue depth-et fognak okozni.

És pontosan ugyanolyan sebességgel megy majd az irás mint a qd=1 -nél, ahogy a fenti mérésből  is látszik.  qd 1 és 512 

https://blog.claryel.hu

És ha két külön fio-t futtatsz párhuzamosan 2 külön file-ba, ugyanarra az eszközre, mindkettőt qd=1-el? (most fejből nincs meg, de lehet, hogy van is erre dedikált paraméter)

Nekem az a feltevésem, hogy (itt most szándékosan valami egyszerű metadata-journaling filerendszert tételezek fel, mondjuk default paraméteres ext4-et, nem pedig zfs szinkron write ahead logot vagy btrfs cow-t) az ioengine=sync nem fog külön file-okba történő adat írás között kikényszeríteni szinkronizálást. Vagyis két független fio összeadva nagyjából a kétszeresét fogja kiadni annak az eredménynek, amit 1 fio futtatásnál kapnál. És ez legalább kb 4-8 instance-ig majdnem lineárisan skálázódni fog, csak utána telítődik.

Ha ma este ráérek, akkor mérek én is párat.

Régóta vágyok én, az androidok mezonkincsére már!

egy 400GB-os Intel P5800X az olyan ~1117 CHF eppen most (kisker brutto). 2.8 CHF/GB.

egy 960GB-os Samsung PM9A3 az olyan ~176 CHF eppen most (kisker brutto). 0.184 CHF/GB.

egy 1TB-os Samsung 980 Pro az olyan ~148 CHF eppen most (kisker brutto). 0.148 CHF/GB.

 

~19x dragabb a P5800X, cserebe a teljesitmenye ennek a tobbszorose. ahova kell, oda megeri. nekem epp ev elejen jott meg egy doboznyi belole, eleg jo cucc :-)

A régebbi sorozatnál (pl. P4800X) HHHL és U.2 csatlakozást tüntet fel az Intel. A P5800X-nél 2.5-ös form factorhoz PCIe 4.0 x4 NVMe-t ír. Ránézésre ugyanaz az U.2/SAS interfész, mint korábban. Ha U.2-es csatlakozó van a szerver alaplapon, akkor azzal működik (Xeon Scalable 2nd gen)?

Horror az ár. Nincs fölösleges 1.6Tb-os meghajtód? :-) 3.2Tb-ost lehet egyáltalán kapni?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( soproni v | 2022. 04. 11., h – 09:49 )

# Dell EMC PowerEdge T440 (PERC H750 RAID)
- 4 x Dell 960GB SATA MU SSD HOT-PLUG Kerettel, 5 év helyszíni gari - 151.000 FT + ÁFA / db

Elégedett vagyok, gyors, minden ok.

# RHE, Rocky, NethServer, MBP14

( hnsz2002 v | 2022. 04. 13., sze – 13:12 )

Szerkesztve: 2022. 04. 13., sze – 13:15

Ha már feltámasztottuk a halott topicot...

Én nem értem miért adják ennyire drágán a brandelt ssd-ket... Értem én hogy az iphonet is megveszik sokan annyiért, de akkor is.

Sok szervert építettünk vagy fejlesztettünk úgy, hogy sima kommersz SATA SSD-t tettük/teszünk bele (desktopokba is egyébként ezeket pakoljuk). Apacer, A-Data, Teamgroup, meg még nem is tudom mik voltak. Egy sem döglött még meg (sem szerverbe, sem desktopba), pedig van olyan konfig ami sok éve megy. Teljesítményben nincs igazán összehasonlítási adatom, mert ugye ugyanazt a vasat kéne mérni valami nagyobb nevű diszkkel vagy brand diszkkel, de egyik géppel sincs teljesítmény probléma, tökéletesen ellátja a feladatát, nyilván fényévvel előtte van bármilyen hdd-nek. A desktopokat kivéve mindenhol RAID van, általában RAID10, illetve napi backup. 150k-ból még a mostani árak mellett is ki lehet hozni simán 6 olcsóbb SSD-t vs. 1-ért adsz annyit. Ha meg mégis megdöglik, akkor akár a sarki boltba bemehetsz, veszel másikat, beteszed és kész.

"Sose a gép a hülye."

mert a brandelt SSD nem fos, nagyon egyszeru.

raknek VALAHA a-data, teamgroup, apacer SSD-t en barmilyen szerverbe (de akar a sajat desktopomba)? a valasz az egyertelmu nem. soha. semmilyen korulmenyek kozott.

es akkor maris nem az olcso fos vs brand a kerdes, hanem az intel/samsung/micron enterprise drive vs Dell drive (ami ugyanaz, csak rebandelve), es rajossz, hogy jee, ugy mar nem is olyan draga, foleg, hogy benne van mondjuk 24x7 4 oran beluli csere, etc.

Mert a nem brandelt fos? Nem ezt látjuk.

OK, és miért is nem tennél? Mert azt nem írtad.

Ha ennyire kell hogy gyorsan legyen cserélve, akkor rászánsz még egy diszk árát (150k/6db=25k), magyarul 175k-ért veszel 7-et, 1-et elteszel a fiókba, és ha megdöglik egy, akkor akár 10 percen belül kicserélted. Vagy beteheted hot-spare-nek ha fizikailag belefér, és beugrik automatán.

Baromira nem látom az előnyt még mindig.

"Sose a gép a hülye."

nem azert olcso, mert a hudecsunya multi lehuz teged a dragabb cuccokon, hanem van anyag benne. emberek, akik letesztelik az FW-t rendesen, az elektronika rendesen meg van epitve, az aram- es homanagement rendben van, a NAND nem gagyi, etc, etc. ezert nem vennek ezekbol.

25k-ert nem tudsz rendes enterprise diszket venni a szabad piacon, en nem tudom te mirol beszelsz.

Senki nem beszélt enterprise diszkekről (bár abba inkább ne menjünk bele, hogy ez az enterprise sokszor bullshit), de a kérdésemre továbbra sem válaszoltál.

Szóval ott tartunk, hogy a kolléga vett 600k-ért 4db enterprise diszket, én meg azt mondtam, hogy inkább veszek 150k-ért 6 olcsót, aztán ha megdöglik esetleg, akkor veszünk másikat. Erre te azzal válaszoltál, hogy dehát garancia meg 4 órán belül cserélik, erre meg én mondtam hogy ha ez ennyire szempont, akkor veszünk 7-et 175k-ért, még mindig 425k-val bentebb vagyunk és azonnal vagy akár 10 percen belül ki lesz cserélve a hibás diszk.

"Sose a gép a hülye."

de a kérdésemre továbbra sem válaszoltál.

Mert pont erről szólt a méricskélés feljebb . Intenziv lemezhasználat esetén, magas iops random szinkron írásnál , -  speciális eset , pl ZFS ZIL lemez -  két nagyságrend lehet  a különbség. (2MB/sec vs 200 MB/sec). 

Egy topic a proxmox forumról - Consumer nvme ssd log-nak és a felére esett a teljeaítmény,

https://forum.proxmox.com/threads/nvme-slog-gives-slower-write-performance.65272/

Proxmox fórumon sok hasonlót találhatsz.

https://blog.claryel.hu

Senki nem beszélt enterprise diszkekről

de, de, arrol szol az egesz. szerverrol beszelunk. ha veszel egy Dell/Supermicro/akarmi branded diszket, akkor az enterprise diszk lesz, nem desktop.

bár abba inkább ne menjünk bele, hogy ez az enterprise sokszor bullshit

???? meselj mar szerinted miert bullshit...

Mert dolgozunk 1-2 nagyobb cégnek, és az látszik, hogy sokszor az enterprise kulcsó valamin (most elsősorban szoftverekre és supportra gondolok), az annyit jelent, hogy 3-4x-es árcímkét (vagy egyáltalán az árcímkét a free helyett) rá lehet tenni anélkül, hogy egyébként bármivel is jobb lenne vagy több lenne a free/community változattól. Cserébe ha valami szar, akkor lehet lobogtatni a számlát meg a licencet, ugynakkor a problémát ha meg akarod oldani, kb. ugyanúgy neked kell kút főből, logikából meg googleből, stackoverflow-ból meg a többiből megoldani, mert a supportnak halvány lila fingja sincs arról (fele annyi se, mint neked), hogy mi a probléma, és teljesen értelmetlen dolgokat kér vagy javasol, vagy totálisan rossz irányba indulna el hibakereséssel.

"Sose a gép a hülye."

Hat, nem tudom. Define "nagy"...

Nagy ceg vagyunk, es nagyoknak dolgozunk. A meretekrol annyit, hogy pl. a storage osszesiteseknel a peta es exa elotagok szerepelnek a beszamolokban.

Semmi esetben se engedhetjuk meg magunknak, hogy csak ugy, komoly support nelkul fogadjunk be illetve nyujtsunk  SW vagy HW termeket. Ezt a beszallitoink es a customereink se engedhetik meg maguknak, ha az ellatasi lancon megyunk jobbra vagy balra. Ki vallalna be mondjuk egy olyat, hogy egy nyari olimpia alatt egyszercsak megall az internet vagy telefonhalozat anelkul, hogy pancellal vedene az ulepet?

A support ebben a kornyezetben nem azt jelenti, hogy egy random munkatarsad valamit egy, a vendor weblapjan uzemelo forumba, ahol majd egy random munkatars irkal valami okosat.

Itt arrol van szo, hogy amint hibat talalsz (rosszabb esetben a customered fut bele elesben), az keresztul megy az erre felkeszult mernokodon (lasd meg, certified engineer), aki eldonti, hogy ez a hiba tenyleg a vendornal van, majd felveszi a kapcsolatot a megfelelo csatornakon kereszul. Erre a vendor szepen ramozdul, es megoldja kozosen a mernokeiddel. Ha kell, akkor repulore ul egy kisebb csapat.

Szigoru meroszamok vannak a hibamegoldashoz. Peldaul 7/24-ben 30 percen belul ACK, 24 oran belul fix/workaround, 72 oran belul kesz javitas. Ez sokba kerul. Nagyon...

Egy másik, kicsit cinikus, de valamennyire tanulságos nézőpont lehet, hogy ha 600k-ért veszed meg a brand disket, akkor nem (feltétlenül) a te tökeid lesznek satuban, ha idő előtt elpukkan az egyik. Ellentétben azzal, amikor a sarki számtech boltból hozod az SSD-ket. Ez az életérzés sokszor megéri a felárat, és nem csak az SSD-re igaz.

Illetve még egy szempont, hogy ha 600k budget van SSD-re, akkor nem veszünk 150-ért, mert a különbözetet nem fogod megkapni, ellenben a későbbi problémákat igen. :)

Minden esetben tájékoztatjuk az ügyfelet arról, hogy ez azért ennyi, azért olcsó, mert nem erre van, ugyanakkor véleményünk szerint teljesen megfelelő.

Emellett valamiért nem akarjátok megérteni a különbséget.... Szóval 150k-ért vesz valamit. Ami nem mondom, hogy ugyanazt hozza, akár teljesítményben, akár élettartamban mint az enterprise, de neki tökéletesen megfelelő. Ha esetleg mégis hullana (ami mint írtam egyáltalán nem jellemző), akkor elfogadja azt, hogy akár újabb 150k-ért venni kell 6 új diszket 2-3 év múlva. De még akkor is a felénél jár (300k vs. 600k)

"Sose a gép a hülye."

Emellett valamiért nem akarjátok megérteni a különbséget.... 

Nem kell mindenhova DC ssd. Viszont van egy olyan szegmense az ssd-k nek, ahol jelenleg 100 szoros a különbség. Ezt azért nem mondhatod "csili vili túlárazott" szerveralkatrésznek. HDD -nél nincs ilyen különbség, smr HDD és 10 k sas HDD között sem.

lemérheted: 

 fio --name=ssdtest --filename=testfile1 --size=1000M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 --ioengine=sync |grep write:

nem plp-s ssd-knél 1.5 MB/sec -et kapsz majd

plp-s sata DC ssdk: 70-100 MB/sec-et

Nvme plp, optane 200- MB/sec.

Volt aki ezekre a mérésekre azt mondta, nem jó a fio. pedig jó.

 

Adatbáziskezelők,  ZFS  (SLOG/ZIL) , iops intenzív lemezhasználathoz célszerű elsősorban.

Az optane-t nem az irodai szerverekhez árazták, de használtan akár magyar szerverboltokban is 1 év garanciával kapsz p36xxx, p37xx Nvme ssdt, egy 1.6 Tb-os 95 ezer, egy új samsung asztali 1 TB-os meg 60 ezer.

https://blog.claryel.hu

Ez a desktop gépem, Teamgroup SATA.



       *-sata 

            description: SATA controller

            product: 9 Series Chipset Family SATA Controller [AHCI Mode]

            vendor: Intel Corporation

            physical id: 1f.2

            bus info: pci@0000:00:1f.2

            logical name: scsi0

            version: 00

            width: 32 bits

            clock: 66MHz

            capabilities: sata msi pm ahci_1.0 bus_master cap_list emulated

            configuration: driver=ahci latency=0

            resources: irq:29 ioport:f0d0(size=8) ioport:f0c0(size=4) ioport:f0b0(size=8) ioport:f0a0(size=4) ioport:f060(size=32) memory:f7d39000-f7d397ff

          *-disk

               description: ATA Disk

               product: TEAM T253X2001T

               physical id: 0.0.0

               bus info: scsi@0:0.0.0

               logical name: /dev/sda

               version: KR

               serial: TPBF2009150030100480

               size: 953GiB (1024GB)

               capabilities: gpt-1.00 partitioned partitioned:gpt

               configuration: ansiversion=5 guid=ae53f75f-e452-415d-9327-63ff66a4a948 logicalsectorsize=512 sectorsize=512




ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1

fio-3.26

Starting 1 process

ssdtest: Laying out IO file (1 file / 1000MiB)

Jobs: 1 (f=1): [w(1)][99.7%][w=5640KiB/s][w=1410 IOPS][eta 00m:01s]

ssdtest: (groupid=0, jobs=1): err= 0: pid=210724: Thu Apr 14 10:45:26 2022

  write: IOPS=747, BW=2988KiB/s (3060kB/s)(1000MiB/342649msec); 0 zone resets

    clat (usec): min=576, max=846489, avg=1279.45, stdev=7235.47

     lat (usec): min=576, max=846490, avg=1279.63, stdev=7235.52

    clat percentiles (usec):

     |  1.00th=[   594],  5.00th=[   594], 10.00th=[   603], 20.00th=[   611],

     | 30.00th=[   635], 40.00th=[   644], 50.00th=[   644], 60.00th=[   660],

     | 70.00th=[   676], 80.00th=[   701], 90.00th=[   742], 95.00th=[   807],

     | 99.00th=[ 30278], 99.50th=[ 45876], 99.90th=[104334], 99.95th=[123208],

     | 99.99th=[204473]

   bw (  KiB/s): min=    8, max= 5928, per=100.00%, avg=2998.73, stdev=2622.91, samples=683

   iops        : min=    2, max= 1482, avg=749.67, stdev=655.71, samples=683

  lat (usec)   : 750=90.96%, 1000=6.41%

  lat (msec)   : 2=0.98%, 4=0.14%, 10=0.47%, 20=0.01%, 50=0.69%

  lat (msec)   : 100=0.24%, 250=0.11%, 500=0.01%, 1000=0.01%

  fsync/fdatasync/sync_file_range:

    sync (usec): min=19, max=213957, avg=55.72, stdev=1072.42

    sync percentiles (usec):

     |  1.00th=[   24],  5.00th=[   26], 10.00th=[   27], 20.00th=[   28],

     | 30.00th=[   30], 40.00th=[   31], 50.00th=[   32], 60.00th=[   32],

     | 70.00th=[   34], 80.00th=[   36], 90.00th=[   43], 95.00th=[   58],

     | 99.00th=[  145], 99.50th=[  206], 99.90th=[  529], 99.95th=[15139],

     | 99.99th=[52691]

  cpu          : usr=0.42%, sys=3.47%, ctx=1029338, majf=0, minf=16

  IO depths    : 1=200.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=0,256000,0,255999 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):

  WRITE: bw=2988KiB/s (3060kB/s), 2988KiB/s-2988KiB/s (3060kB/s-3060kB/s), io=1000MiB (1049MB), run=342649-342649msec



Disk stats (read/write):

    dm-5: ios=0/1806344, merge=0/0, ticks=0/664867, in_queue=664997, util=99.73%, aggrios=0/1806386, aggrmerge=0/0, aggrticks=0/462973, aggrin_queue=463101, aggrutil=99.70%

    dm-4: ios=0/1806386, merge=0/0, ticks=0/462973, in_queue=463101, util=99.70%, aggrios=9524/1543458, aggrmerge=1/269373, aggrticks=304916/426053, aggrin_queue=1008493, aggrutil=97.88%

  sda: ios=9524/1543458, merge=1/269373, ticks=304916/426053, in_queue=1008493, util=97.88%

Ez pedig egy szerver, Samsung NVME. (Azt hittem, megmarom magam, míg végez...)



       *-pci:1 

            description: PCI bridge

            product: Cannon Lake PCH PCI Express Root Port #21

            vendor: Intel Corporation

            physical id: 1b

            bus info: pci@0000:00:1b.0

            version: f0

            width: 32 bits

            clock: 33MHz

            capabilities: pci pciexpress msi pm normal_decode bus_master cap_list

            configuration: driver=pcieport

            resources: irq:123 memory:51000000-510fffff

          *-nvme

               description: NVMe device

               product: SAMSUNG MZVLB1T0HALR-00000

               vendor: Samsung Electronics Co Ltd

               physical id: 0

               bus info: pci@0000:02:00.0

               logical name: /dev/nvme1

               version: EXA7301Q

               serial: S3W6NX0M911083

               width: 64 bits

               clock: 33MHz

               capabilities: nvme pm msi pciexpress msix nvm_express bus_master cap_list

               configuration: driver=nvme latency=0 nqn=nqn.2014.08.org.nvmexpress:144d144dS3W6NX0M911083      SAMSUNG MZVLB1T0HALR-00000 state=live

               resources: irq:16 memory:51000000-51003fff




ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1 

fio-3.19

Starting 1 process

Jobs: 1 (f=1): [w(1)][100.0%][w=491KiB/s][w=122 IOPS][eta 00m:00s]

ssdtest: (groupid=0, jobs=1): err= 0: pid=508482: Thu Apr 14 11:12:45 2022

 write: IOPS=139, BW=557KiB/s (571kB/s)(1000MiB/1837719msec); 0 zone resets

   clat (msec): min=2, max=179, avg= 6.98, stdev= 1.98

    lat (msec): min=2, max=179, avg= 6.98, stdev= 1.98

   clat percentiles (usec):

    |  1.00th=[ 3097],  5.00th=[ 3228], 10.00th=[ 3359], 20.00th=[ 5473],

    | 30.00th=[ 7373], 40.00th=[ 7504], 50.00th=[ 7570], 60.00th=[ 7701],

    | 70.00th=[ 7767], 80.00th=[ 7963], 90.00th=[ 8225], 95.00th=[ 8586],

    | 99.00th=[11469], 99.50th=[12518], 99.90th=[15270], 99.95th=[16188],

    | 99.99th=[20055]

  bw (  KiB/s): min=  280, max= 1280, per=100.00%, avg=557.74, stdev=184.43, samples=3668

  iops        : min=   70, max=  320, avg=139.26, stdev=46.15, samples=3668

 lat (msec)   : 4=18.95%, 10=78.12%, 20=2.91%, 50=0.01%, 250=0.01%

 fsync/fdatasync/sync_file_range:

   sync (usec): min=60, max=142913, avg=187.69, stdev=565.79

   sync percentiles (usec):

    |  1.00th=[   73],  5.00th=[   80], 10.00th=[   95], 20.00th=[  100],

    | 30.00th=[  109], 40.00th=[  128], 50.00th=[  147], 60.00th=[  157],

    | 70.00th=[  163], 80.00th=[  169], 90.00th=[  180], 95.00th=[  202],

    | 99.00th=[ 3097], 99.50th=[ 3490], 99.90th=[ 7177], 99.95th=[ 7504],

    | 99.99th=[ 9765]

 cpu          : usr=0.29%, sys=1.57%, ctx=1285438, majf=0, minf=13

 IO depths    : 1=200.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=0,256000,0,255999 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):

 WRITE: bw=557KiB/s (571kB/s), 557KiB/s-557KiB/s (571kB/s-571kB/s), io=1000MiB (1049MB), run=1837719-1837719msec



Disk stats (read/write):

   dm-0: ios=0/1051088, merge=0/0, ticks=0/1919477, in_queue=1919477, util=100.00%, aggrios=3/1589441, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%

   md1: ios=3/1589441, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=2/1054517, aggrmerge=0/20151, aggrticks=1/1755009, aggrin_queue=1755011, aggrutil=99.02%

 nvme0n1: ios=4/1054518, merge=0/20150, ticks=3/1752099, in_queue=1752102, util=98.89%

 nvme1n1: ios=0/1054516, merge=0/20152, ticks=0/1757919, in_queue=1757920, util=99.02%

"Sose a gép a hülye."

Erről beszléltünk: 

Ez pedig egy szerver, Samsung NVME.

WRITE: bw=557KiB/s (571kB/s), 557KiB/s-557KiB/s (571kB/s-571kB/s), io=1000MiB (1049MB), run=1837719-1837719msec

Egy HDD -nél ez 400 Kib/s. 

Nem szokták elsőre elhinni. Persze ettől még lehet jó, de jobbnak gondolják.
 

https://blog.claryel.hu

tok mindegy, mert az is szar.

itt van egy kozepes enterprise drive (Samsung SAMSUNG MZQL23T8HCLS-00A07, PM9A3, 3.84TB): write: IOPS=74.4k, BW=291MiB/s (305MB/s)(17.0GiB/60001msec); 0 zone resets

itt van egy optane (Intel SSDPF21Q400GB, P5800X): write: IOPS=94.0k, BW=371MiB/s (389MB/s)(21.7GiB/60001msec); 0 zone resets

itt meg egy Samsung 970 PRO: write: IOPS=462, BW=1848KiB/s (1892kB/s)(108MiB/60001msec); 0 zone resets

Igen,  de leginkább a tranzakciókezelés szempontjából. A te saját mérésedből is látszik, hogy egy nvme samsung consumer ssd ugyanolyan lehet  mint egy hdd:  400 vs 570 kbájt/sec. 

Nem szokták elhinni. Higgyek a szememnek vagy a marketingnek?  Ott a nevében a pro. Vagyis asztali, de professzionális, azaz top termék.

Vagy nem.

https://blog.claryel.hu

CSAK  a tranzakciókezelésre érvényes a megálapítás. Aszinkron - és vagy, szekvenciális- irásnál sokkal  jobb  mint egy HDD. 200 Megabást/sec vs 500 -1500 Megabájt/sec. 

Mi CSAK AZ IOPPS  igényes, másképp kis latency-t igénylő intenziv lemezhasználatról vitázunk. Minél kisebb a latency annál drágább az ssd, Optane-nél ez kell megfizetni.

Ahogy csökken a latency , úgy nő az ssd ára. Fajlagosan az optane nagytestvére, a  permanens memória viszont valamivel olcsóbb  (gigabájtra átszámolva) mint a DRAM, igaz itt nincs 4.8,16 GB , 128 GB-tal kezdődik egy modul.

Ezt azért kétkedve fogadom, hogy annyit tud, mint egy bármilyen HDD.

Most mérted le. És hát kinek higgyél, a marketingnek vagy a saját mérésednek. Hát a marketingnek, természetesen. 

Mégegyszer  Proxmoxos fórumról 2020 februári  topic  , WD SN750 nvme, kb ugyanazt kapta amit mértél: Nvme asztali ZIL/SLOG ssd-nek és felére eseik az IOPS:

https://forum.proxmox.com/threads/nvme-slog-gives-slower-write-performance.65272/

https://blog.claryel.hu

Ez azert egy igen massziv topic :)

Komoly folytatasos teleregeny lenne, ha valaki vallalkozna ra. Eleve egy szep tema a blokkos eszkozok kulonfele teljesitmeny-parameterei, aztan a benchmarkolas buktatoi, es vegul meg ennel is sokkal nagyobb temakor, hogy az egyes alkalmazasoknak mikor mi kell belole es miert. Itt aztan vannak boven nagyon mely rabbithole-ok tranzakciokezelessel, elosztott rendszerekkel, meg ugy altalaban a filerendszerek lekivilagaval (incl az advanced megoldasok, mint brtfs, ceph, zfs, amik kb alapjaiban meg tudjak valtoztatni a felettuk futo alkalmazas IO profiljat).

Egy feleves egyetemi tantargy siman kijonne belole, es akkor meg mindig nem fedtel le mindent.

Elismeresem annak aki ebbol tudna egy "tldr" osszefoglalo blogposzt irni ugy, hogy ne legyen durva elvarratlan szalak benne.

Régóta vágyok én, az androidok mezonkincsére már!

lazan kapcsolodik, hogy egyszer tartottam egy eloadast arrol, hogy hogyan csaljunk block storage benchmarkon... :) mindig megkerdeztem a kozonseget, hogy mondjanak mar egy metrikat, ami szerintuk fasza (a kulcs az _egy metrikan_ van), aztan hoppa, mar ki is dobta a rendszer... :D

mindig orom volt nezni az allakat, meg a megvilagosodast.

 

btw kulon blogposztot nem er, de multhet penteken hivatalos ceges hatszelet kapott az az uj blokk storage rendszer, amirol irtam, hogy elkezdjuk majd nyilt forraskoddal, szoval lesznek itten ujdonsagok! :-D

Úgy értem pl. kezdjük soho/otthoni felhasználásra.

Van sata3, meg nvme csatolós SSD az otthoni torrentszerverbe. Sata3-nak ma már látványosak a korlátai, amik ezek és így lehet előhozni: .....

Vagy pl. a SATA3 elméleti max. átviteli sebessége valahol 550-600MB/sec körül van, a 870 EVO-m mégse tud gyorsabban olvasni, mint 250-300 MB/sec, ez azért van, mert:.......

A samsungnak van perpill 870 evo, 870 qvo, ezek között a különbség teljesítményben:.....

De aztán jön a 970 / 980, Pro, nem-pro, plus, nem-plus. DRAM és DRAM-nélküli. Van ami már csak a system RAM-ot használja vmi trükkös megfontolásból. Ezek teljesítménye így alakul:......

A dobozra írt nagy számok 3000MB/sec, vagy 10ezer MB/sec akkor érhetőek el csak, ha így méred vagy ezt csinálod: ........

A random 4K, queue1-depth1, stb. eredmények azt mutatják, hogy:........

És akkor szintet lépünk a gagyi pistike otthoni szarjáról a nagyvállalati ssdk-hez. Ahol látványos a különbség a dupla-tripla-tízszeres árkülönbség miatt, pl. ebben:......

Ilyesmire gondoltam.

 az advanced megoldasok, mint brtfs, ceph, zfs, amik kb alapjaiban meg tudjak valtoztatni a felettuk futo alkalmazas IO profiljat.

Ez is egy "új szál", nem is tudom elvarrni.  Például,  proxmox szerver default zfs , rajta egy VM guest , mysql-lel. Mysql szintén default, ir egy  16 K-s blokkot, utána szinkron fsync() , lemezre írás, zfs meg ir akár 160 KB-ot.  mindennel együtt. Tettünk  ide egy tizszer gyorsabb ssd-d, aztán mégis ott vagyunk ahol voltunk?  Hát ez egy érdekes kérdés. 

Ha van lehetőséged, használj plp-s ssd-t ilyen környezetben, használtan akár. Az nem igaz, hogy az ssd-k nek van egy széles skálája , és a top consumer ssd -k már majdnem szerver szintűek. 

SSD-k a latency alapján különálló, eltérő csoportokban vannak, nem pedig lineárisan elszórva.  Csoprton belül persze nem egyformák, 1 év garancia 5 év garancia, TBW, "name space"-s Nvme ssd-k  stb. 

https://blog.claryel.hu

Hat, ha megfelelnek az ilyen odadobott valaszok anelkul, hogy tenyleg ertened mi miert van...

"Sata3-nak ma már látványosak a korlátai, amik ezek és így lehet előhozni:...."

Pl veszel egy 10Gbit/s-es halozati kartyat, es epitesz komplett halozatot hozza. Egy torrent szerverben nem hiszem, hogy enelkul elo tudnad hozni a "latvanyos" korlatait.

"a SATA3 elméleti max. átviteli sebessége valahol 550-600MB/sec körül van, a 870 EVO-m mégse tud gyorsabban olvasni, mint 250-300 MB/sec, ez azért van, mert:......."

Ez megmondhatatlan, anelkul, hogy a pontos meresi modszert, setup reszleteit rogiztened. SATA3-bol soha senki nem latott 600MB/s-et kijonni. Az 550 is elegge necces, a valos "goodput" maximuma valahol 530-540MB/s korul van.

"A samsungnak van perpill 870 evo, 870 qvo, ezek között a különbség teljesítményben:....."

Here you go:

https://www.anandtech.com/show/15887/the-samsung-870-qvo-1tb-4tb-ssd-re…
https://www.anandtech.com/show/13633/the-samsung-860-qvo-ssd-review
https://www.phoronix.com/scan.php?page=article&item=samsung-870-qvo
https://www.phoronix.com/scan.php?page=article&item=samsung-860-qvo

"Van ami már csak a system RAM-ot használja vmi trükkös megfontolásból. Ezek teljesítménye így alakul:......"

Here you go:

https://www.phoronix.com/scan.php?page=article&item=samsung-980-linux
https://www.anandtech.com/show/16504/the-samsung-ssd-980-500gb-1tb-revi…

"A dobozra írt nagy számok 3000MB/sec, vagy 10ezer MB/sec akkor érhetőek el csak, ha így méred vagy ezt csinálod: ........"

dd if=/dev/nvme0n1p1 of=/dev/null bs=1M

"A random 4K, queue1-depth1, stb. eredmények azt mutatják, hogy:........"

...mennyi az iras/olvasas latencyje. Ha olyan alkalmazasod/DB-d/filerendszered van, ami eros adatkonzisztencia garantalas miatt minden irasmuveletet bevar es addig nem megy tovabb, amig az eszkoz vissza nem jelezte, hogy az irt adat stabil tarban van, akkor ez szamodra egy fontos metrika lesz. Ha csak ext4-en torrentezel, akkor nem ez lesz relevans. Olvasas oldalon pedig, ha az alkalmazasod olyan, hogy ez egyik felolvasott blokk tartalmabol tudja meg, hogy melyik lesz a kovetkezo felolvasando blokk (lancolt lista, b-fa, graf bejaras, kodtoreshez rainbow table stb.), akkor random read qd=1 lesz relevans.

"Ahol látványos a különbség a dupla-tripla-tízszeres árkülönbség miatt, pl. ebben:......"

Hogy van rajta egy csomo kondenzator, ami a tap elvesztese utan par masodpercig eleg aramot ad a vezerlonek, hogy a dram cache-bol ki tudja irni a dirty adatokat a flash-be. Igy nem kell felni, hogy elvesznek user adatok a DRAM-bol, ezert a gyarto egyaltalan meri a user adatokat write buffer-elni DRAM-ba. Ezzel a host feloli qd=1 irasoknal nem kell bevarni a flash latency-jet, a teljesitmenye akkor is olyan lesz, mintha qd=16 qd=32 vagy ilyesmi lenne.

Aztan a firmware nem arra van optimalizalva, hogy rovid ideig amilyen gyorsan csak lehet, minel tobb irast benyeljen, majd utana idle idoben szepen berendezgesse a vegleges helyukre a flash blokkokba. Helyette egy alacsonyabb teljesitmenyszintet kell tudjon, de azt gyakorlatilag korlatlan ideig stabilan.

Tovabba a firmware nincs kifejezetten mondjuk NTFS filerendszer (rosszabb esetben konkret benchmark alkalmazasok) tipikus IO mintaira raoptimalizalva, hogy a tesztekben jol mutasson. A gyakrolatban meg, a user ugy sem veszi eszre, hogy tul lassu lenne... (Hint: erdemes osszenezni az Anadtech-es windows-on futattott benchmark eredmenyeket es a phoronix Eredmenyeket, sokszor teljesen mas sorrend jon ki)

Meg tovabba van olyan amelyik tud un. "zonas" uzemmodot, amikor a flash translation layer kikapcsol, es az oprendszerre vagy DB engine-re bizza a flash minden nyugjenek (elborult blokkmeretek, kulon iras es erase muvelet, wear levelling) kezeleset. Ami nehany specializalt esetben lehet optimalisabb, mintha az SSD vezerlo emulalna egy normali block device-ot, amit a DB engine hasznalna fogalmatlanul nagyon szerencsetlen modon.

Aztan van olyan (igen draga) flash pl Samsung Z-NAND, ami latency-re optimalizalt, cserebe az adatsurusege sokkal rosszabb, emiatt fajlagosan dragabb. Meg vannak az ilyen egzotikumok, mint Optane, meg MRAM, amik szinten sokkal jobb latencyvel rendelkeznek, sokkal tobb ujrairast kibirnak, cserebe kis kapacitas, nagy ar, es esetleg rovid adatmegtartasi ido jar.

Régóta vágyok én, az androidok mezonkincsére már!

Meg tovabba van olyan amelyik tud un. "zonas" uzemmodot, 

nem tudni ebből mi lesz, mindenesetre "next generation ssd" -ként emlegetik, ZNS SSD néven. Rájöttek hogy a HDD-s smr belső felépitése  ,- ami olyan amilyen, vagyis borzalmas- , nagyon hasonlít az ssd-k struktúrájához, és ide viszont nagyon is jó.

https://blog.claryel.hu

Csak érdekességképp... Laptopom Apacer... A legolcsóbb 1TB-os SSD volt, amikor vettem. Nagyjából ugyanazt hozza mint a Teamgroup, ami viszont érdekes, hogy míg a teamgrouppal ugrált a sebesség kb. 90K és 5900K között, ez stabilan hozta a sebességet kb. 2600K és 3000K között.

        *-sata
             description: SATA controller
             product: Wildcat Point-LP SATA Controller [AHCI Mode]
             vendor: Intel Corporation
             physical id: 1f.2
             bus info: pci@0000:00:1f.2
             logical name: scsi0
             version: 03
             width: 32 bits
             clock: 66MHz
             capabilities: sata msi pm ahci_1.0 bus_master cap_list emulated
             configuration: driver=ahci latency=0
             resources: irq:44 ioport:30a8(size=8) ioport:30b4(size=4) ioport:30a0(size=8) ioport:30b0(size=4) ioport:3060(size=32) memory:f123c000-f123c7ff
           *-disk
                description: ATA Disk
                product: Apacer AS350 1TB
                physical id: 0.0.0
                bus info: scsi@0:0.0.0
                logical name: /dev/sda
                version: 3PE0
                serial: A45A079A108600191597
                size: 953GiB (1024GB)
                capabilities: gpt-1.00 partitioned partitioned:gpt
                configuration: ansiversion=5 guid=1af624e0-4e68-499a-b3f8-ba8327559daa logicalsectorsize=512 sectorsize=512

ssdtest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1
fio-3.26
Starting 1 process
ssdtest: Laying out IO file (1 file / 1000MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=2986KiB/s][w=746 IOPS][eta 00m:00s]
ssdtest: (groupid=0, jobs=1): err= 0: pid=519980: Fri Apr 15 07:06:02 2022
  write: IOPS=672, BW=2688KiB/s (2753kB/s)(1000MiB/380904msec); 0 zone resets
    clat (usec): min=1074, max=404399, avg=1413.13, stdev=2193.75
     lat (usec): min=1075, max=404400, avg=1413.61, stdev=2193.78
    clat percentiles (usec):
     |  1.00th=[ 1139],  5.00th=[ 1156], 10.00th=[ 1172], 20.00th=[ 1205],
     | 30.00th=[ 1221], 40.00th=[ 1237], 50.00th=[ 1270], 60.00th=[ 1287],
     | 70.00th=[ 1336], 80.00th=[ 1401], 90.00th=[ 1516], 95.00th=[ 1762],
     | 99.00th=[ 4178], 99.50th=[ 4752], 99.90th=[ 7963], 99.95th=[34866],
     | 99.99th=[68682]
   bw (  KiB/s): min=    8, max= 3152, per=100.00%, avg=2690.47, stdev=647.87, samples=761
   iops        : min=    2, max=  788, avg=672.61, stdev=161.97, samples=761
  lat (msec)   : 2=96.16%, 4=2.66%, 10=1.09%, 20=0.01%, 50=0.06%
  lat (msec)   : 100=0.01%, 250=0.01%, 500=0.01%
  fsync/fdatasync/sync_file_range:
    sync (usec): min=26, max=431911, avg=66.38, stdev=1027.06
    sync percentiles (usec):
     |  1.00th=[   33],  5.00th=[   35], 10.00th=[   37], 20.00th=[   40],
     | 30.00th=[   42], 40.00th=[   44], 50.00th=[   47], 60.00th=[   50],
     | 70.00th=[   54], 80.00th=[   60], 90.00th=[   74], 95.00th=[   95],
     | 99.00th=[  167], 99.50th=[  217], 99.90th=[  971], 99.95th=[13829],
     | 99.99th=[17957]
  cpu          : usr=0.97%, sys=6.69%, ctx=1034245, majf=0, minf=15
  IO depths    : 1=200.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=0,256000,0,255999 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):
  WRITE: bw=2688KiB/s (2753kB/s), 2688KiB/s-2688KiB/s (2753kB/s-2753kB/s), io=1000MiB (1049MB), run=380904-380904msec

Disk stats (read/write):
    dm-5: ios=2352/1805804, merge=0/0, ticks=8033/433945, in_queue=442081, util=99.86%, aggrios=2352/1805860, aggrmerge=0/0, aggrticks=7784/349038, aggrin_queue=356924, aggrutil=99.76%
    dm-4: ios=2352/1805860, merge=0/0, ticks=7784/349038, in_queue=356924, util=99.76%, aggrios=14186/1519256, aggrmerge=3066/292868, aggrticks=351110/444555, aggrin_queue=1053076, aggrutil=99.41%
  sda: ios=14186/1519256, merge=3066/292868, ticks=351110/444555, in_queue=1053076, util=99.41%

"Sose a gép a hülye."

Az én tapasztalatom az volt, hogy anno Samsung 840 Pro és 850 Pro-kat raktunk Jenkins slave alá, IBM szerverbe. Ha elpusztul, elpusztul, nincs reprodukálhatatlan adat rajta, a gép ansible-el gyorsan újrahúzható. Kb 1-2 hét használat után olyan szinten belassultak, hogy az eredeti 10k-s SAS HDD gyorsabb volt. Egy párszor eljátszottuk, hogy kivettük, külön letrimmeltük, secure erase, utána megint gyors, megint 1-2 hétig. Egy darabig küzködtünk vele, hogy csak a 2/3-át particionáljuk be, meg a TRIM-et próbáltuk különféle trükkökkel megoldani, hogy a SAS kontroller áteressze.

Aztán beláttuk, hogy a desktop SSD egyszerűen nem bírja, ha tartósan szerver workload-ot kap. Nem romlik el, nem veszít adatot, de használhatatlanul lelassul, és magától nem nagyon recover-el.

Nyilván nem tudom, hogy ez az évekkel ezelőtti tapasztalat a mai típusokra mennyire igaz.

Régóta vágyok én, az androidok mezonkincsére már!

Pedig a 850 Pro az egyik legjobb konzumer SATA SSD. Ahogy írod is, nem engedtétek át a TRIM-et, az volt a baj. Secure erase előtt felesleges a TRIM, mert a secure erase önmagában megfelel egy teljes meghajtófelületű TRIM-nek. Átlag desktopban akár évekig is elvan egy SSD TRIM nélkül, de szerveres terhelés mellett jobban rá van szorulva. Ez lyen, emiatt a TRIM-et át kell engedni egész lemezes titkosításokon, RAID-ten, LVM-en, virtuális gépeken, mindenféle technológián, amit SSD-k fölé húzol.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ez sajnos nem választás kérdése volt. Az LSI SAS kontrolleren semmilyen trükkel nem lehetett átvinni a TRIM-et.

A secure erase és a külső gépben végzett trim külön-külön próbálkozás volt. A trim magában nem tudta teljesen visszahozni a teljesítményt (azért vicces, mert ez régen a Sandforce vezérlős SSD-k tipikus baja volt, de kellő abuzálással a Samsungokat is ki lehetett annyira fektetni).

Régóta vágyok én, az androidok mezonkincsére már!

( soproni v | 2022. 04. 13., sze – 16:31 )

hardver költség [ sokkal < ] szoftver + üzemeltetés költségei

# RHE, Rocky, NethServer, MBP14

( muszashi | 2022. 04. 13., sze – 18:40 )

Nekem több helyen is futnak Intel SSD-k gond nélkül HW RAID és SW RAID-ben is. DC S3510 és D3-S4610 sorozatúak, 400 GB-tól 960-ig bezárólag.

Kernel Pánik csatorna

( BognarB v | 2022. 04. 14., cs – 12:28 )

Érdemes PH-n szétnézni, szoktak lenni jó Enterprise osztályú SSD-k, bár főként SATA csatival. Én szerencsésen kifogtam egy jó eladót, tőle jött több Intel 710 -otthonra-, volt amiben 42GB írás volt, meg 300 nap..  (apropó, SMART értékeket nem lehet felülírni? :) )
Majd ZFS-sel kíváncsi leszek, hogy mit hoz az otthoni cuccokkal szemben.

Linux parancsok, kezdőknek

( igor | 2022. 04. 14., cs – 22:49 )

Kisebb dedikalt node-oknal nekem nagyon bevalt az elmult 2-3 evben az NVME + Intel VROC parositas.