Test: SSD-er i RAID 0 – del 1

[Cthulhu]

Men firedobbel ytelse er ikke nødvendigvis firedobbel nytelse.

 

Test: SSD-er i RAID 0 – del 1

[Khaffner]

Hvordan er ytelsen i forhold til samme oppsett med RAID 1?

[martin808]

Hvordan er ytelsen i forhold til samme oppsett med RAID 1?

RAID 1 er speiling så det vil gå litt saktere en med kun 1 SSD

[Gjest Slettet+513]

Burde teste Force Series 3 også når det lar seg gjøre. Max Random 4k Write (using IOMeter 08): 85k IOPS

[GullLars]

Jeg har en kommentar angående PCMark Vantage

Når vi går i detalj er det unektelig en del merkelige resultater som kommer fram her. Ved siden av de litt merkelige OCZ-resultatene i Windows Defender-testen, er det flere ting vi må sette spørsmålstegn ved. Hvorfor gjør en Corsair F80A det best i import av bilder? Hvorfor gjør RAID-et det så mye bedre ved videoredigering, samtidig som det ikke er forskjell på RAID 0 med to, tre eller fire SSD-er?

 

Her frykter vi at problemet – for å si det sånn – ikke nødvendigvis ligger selve RAID-et, men at det heller er PCMark Vantage som til en viss grad er problemet. Men i så fall kan det også være slik for mye annen programvare.

Image import vet jeg ikke helt hvorfor skalerer dårligere, men det tyder på at den er avhengig av latency, bruker veldig små filer (mindre enn stripe size), og ikke inneholder parallellitet.

Videoredigering med skalering over 2x fra singel til 2 i RAID i PCMark Vantage er et kjent fenomen som kommer av write cache på intel southbridge. Dette kan gjøre et mye større utslag enn vist her, og gi betydelig bedre score.

 

Som en liten kommentar burde dere kjøre en runde til med 4x RAID-0 med 16KB stripe size og sammenligne med resultatene på 128KB, det er forskjell i PCMark.

 

Poster mer etter jeg har lest ferdig.

[arcade]

Noen som vet om det er støtte for Trim på dedikerte hardware raid kontrollere?

[GullLars]

OK, her kommer resten

 

Et annet viktig punkt er mangelen på Trim-støtte i et slikt RAID. Uten Trim vet vi at ytelsen stadig vil synke, noe som betyr at du vil være nødt til å nullstille (Secure Erase) SSD-ene med ujevne mellomrom dersom du vil holde farten oppe. En slik nullstilling betyr at du mister alle data og må sette opp hele sulamitten på nytt.

Dette stemmer ikke helt. Uten TRIM vil ytelsen vil reduseres fra "fresh" over tid, men det er ikke en endeløs reduksjon. SSDer har 3 faser av ytelsesreduksjon; fersk ut av boksen (FOB), overgangsfasen der ytelsen synker, og til slutt "steady-state" der ytelsen stabiliserer seg på et punkt. Dette punktet avhenger av SSDen, bruksmønsteret man har, og hvor mye reservert plass som er satt av på SSDen.

 

Ved "worst-case" (4KB random write med 100% last over hele mediet) er steady-state grovt lik [FOB]*[overprovisjonering], typisk 5-50K * 7-14% (0,07-0,14), som gir ca 500~5000 IOPS.

REF: http://www.snia.org/sites/default/files/SSS_PTS_Whitepaper_Nov2010.pdf

Med TRIM blir overprovisjonering dynamisk, og regner også med ledig formatert plass.

Om man ønsker å redusere ytelsestapet i steady-state for RAID kan man øke overprovisjonering ved å kjøre Secure-Erase og ikke formatere all ledig plass. Jeg har ingen ekstra OP på mitt OS RAID (4x C300 64GB), og ytelsen er fortsatt innen 90% av ny etter 6mnd bruk. Dette er fordi mitt bruksmønster ikke har overveldende mye random writes i forhold til seq writes.

 

 

Når dere målte med ATTO og fant at skriveytelsen og leseytelsen toppet ut på hhv. ~500MB/s og ~700MB/s er dette pga. båndbreddebegrensning fra ICHxR. Nye *67 kort med 2x 6Gbps porter kan dytte over 1000MB/s, og AMB SB850 kan klare 1200MB/s.

 

Noen som vet om det er støtte for Trim på dedikerte hardware raid kontrollere?

Nei, så langt jeg vet støtter ingen dedikerte HW-RAID kort TRIM, og ingen åpne løsninger støtter TRIM for RAID arrays.

OCZ reklamerte med TRIM på deres egne Z-drives (som er en lukket RAID løsning) som de fikk til gjennom custom firmware.

[lazyjacket]

Er det noen som vet hvordan Intel sine SSD-er fungerer i RAID 0, tenker det da på støtte for TRIM. Ja, har lest at per nå finnes det ingen kontroller som gjør det mulig for støtte for TRIM. Men Intel har jo denne Toolbox, vil denne klare å sende TRIM kommandoen når diskene er i RAID 0 ?

[GullLars]

Når det gjelder RAID og ytelse er det greit å forklare ytelse til lagringsmedie.

 

Ytelse er delt i latency og throughput.

 

Latency er viktig for små blokk random IOPS. Det er hovedsaklig dette som gjør at SSDer yter bedre enn harddisker for OS og programmer, og gjør at CPU ikke trenger å vente så lenge på å få små filer før den kan fortsette med arbeidet.

 

Throughput er hvor mange MB/s lagringsmediet kan levere, og avhenger av blokk størrelse, sekvensiell vs tilfeldige aksessmønster, og parallellitet. Harddisker har god sekvensiell throughput ved både små og store blokk størrelser, men med en gang det blir et snev av tilfeldige aksesser ødelegger latency for throughput. Harddisker har heller ikke noen intern paralellitet, så det er lite throughput å hente fra parallell last, men med NCQ og tilstrekkelig parallell last (16-32 utestående forespørsler = QD) kan harddisker faktisk øke throughput med 2-3x, men dette med kostnad i latency (16-32 / 2-3 = 8-11x høyere latency).

 

RAID's oppgave er hovedsaklig å øke throughput, men man kan faktisk også redusere latency for aksesser som er større enn stripestørrelsen.

RAID øker throughput for sekvensiell last tilnærmet lineært (singel ytelse * enheter), og tilfeldig last med parallellitet (lignende 1+[singel ytelse]*(1/[QD-[1+x]). SSDer har allerede noe tilsvarende RAID internt typisk med 4-8 enheter (kanaler), så for å tjene throughput på parallellitet må man somregel QD være 1/2 -2/3 av singel SSD kanaler. Med harddisker i RAID er skaleringen i forhold til singel bedre ved lav QD da en harddisk ikke har nevneverdig intern parallellitet å hente ut.

 

RAID har også noen andre kjekke fordeler over singel, som kommer av cache. Om cache brukes smart kan man buffre skriveoperasjoner og gjøre sekvensiell streaming til større blokker, eller små tilfeldige til en kø og øke throughput. Man kan også bruke cache til read-ahead og sørge for at sekvensiell lesing gjøres så nære maks hastighet som mulig, og gjøre data klart om det er pauser i de sekvensielle forespørslene. Dette kan i teorien gjøres internt i lagringsenheter, og noen modeller gjør det i større elle mindre grad.

 

RAID cache har også en annen kjekk fordel om det er litt størrelse på den ved å buffre en viss mengde data med høy hastighet uten at det skrives til lagringsmediet, og om hele mengden skriv passer i bufferen etterfulgt av en viss tid med lav eller ingen belastning kan det skjule skrivehastigheten til lagringsmediet og få det til å se mye raskere ut.

 

Som en metafor kan man sammenligne RAID med flerkjernede prosessorer. For oppgaver som bare belaster èn tråd hjelper det ingen ting å ha fler kjerner, men om det samtidig kjører oppgaver for fler kjerner kan de andre avlaste, og om man har nok tråder (parallellitet) i arbeidet skalerer ytelsen veldig godt.

Man kan sammenligne en HDD med en Pentium 4 @ 4GHz, og en SSD med en 4-6kjerne nehalem/sandy, og SSD RAID på en måte en multi-socket server eller et lite cluster av prosessorer.

 

Håper dette var interresant for noen der ute

[GullLars]

Noen som vet om det er støtte for Trim på dedikerte hardware raid kontrollere?

Nei, så langt jeg vet støtter ingen dedikerte HW-RAID kort TRIM, og ingen åpne løsninger støtter TRIM for RAID arrays.

OCZ reklamerte med TRIM på deres egne Z-drives (som er en lukket RAID løsning) som de fikk til gjennom custom firmware.

 

Er det noen som vet hvordan Intel sine SSD-er fungerer i RAID 0, tenker det da på støtte for TRIM. Ja, har lest at per nå finnes det ingen kontroller som gjør det mulig for støtte for TRIM. Men Intel har jo denne Toolbox, vil denne klare å sende TRIM kommandoen når diskene er i RAID 0 ?

TRIM er ikke støttet for arrays (RAID oppsett) på hovedkort heller. Intel toolbox fungerer ikke på RAID, men om du har harddisker i RAID og en singel SSD med OS på samme kontroller (non-member) får du TRIM med intel RST drivere, men jeg vet ikke om du kan kjøre toolbox på den da.

 

Om noen er bekymret for ytelsesdegradering på RAID, og har mer plass enn de trenger på RAIDet går det an å sette av ekstra plass for å sørge for at skriveytelsen stabiliserer seg på et høyere nivå. Om man lar være å lage partisjon på 20-25% av RAIDet, og det er opprettet etter alle SSDene enten er nye ut av boksen eller har blitt kjørt gjennom HDDerase, skal man misbruke RAIDet veldig hardt (tilsvarende lang tortur-test) for å få et merkbart ytelsestap.

[goooser]

Edit: faila vist litt med å sjekke kilden min :<

Endret 19. juni 2011 av goooser

[madammim]

Så det å ikke parisjonere 20-25% kan være et triks på singel SSD som ikke har trim?

[Shruggie]

Jeg savner videre utvikling rundt SSD. Feks, raidkontrollere med funksjoner som SSDer trenger, uten funksjoner som hdder trenger... Filsystemer som er laget spesielt for SSD, osv.

 

Må innrømme at jeg ikke vet så mye om temaet, men av det jeg skjønner er det fremdeles mye uoptimalisert rundt SSDen.

[GullLars]

Så det å ikke parisjonere 20-25% kan være et triks på singel SSD som ikke har trim?

Ja. 20-25% er i øvre laget, da burde du være veldig godt forberedt for veldig hard bruk, eller tilnærmet ingen degradering ved normal bruk med de fleste SSDer (som ikke har TRIM tilgjengelig). SSDer kommer med 7% reservert minimum, og dette er standard definert av JDEC. Utover det har noen SSDer litt ekstra. I følge prinsippet 1/[OP] vil du med 7+20-25% ende opp rundt 25-30% spare area, som vil gi worst case ca 25-30% av ny ytelse for random writes (RW) (som er 3,5-4,3x standard worst case). Om du starter med 10K IOPS blir da 2500-3300. Om du starter med 50K blir det ca 12,5-16K. Går du høyere enn 30-33% (totalt spare area) begynner "diminishing returns" å tre inn i bildet.

 

For de fleste vanlige OS og program bruksområder vil du ikke ha høy nok andel random writes til å tydelig merke en reduksjon i ytelse selv med 7% spare area.

Øker du det med 5% av brukerområdet til 11% total spare area øker du minimum worst-case ytelse med ca 1,6x.

Øker du med 10% ender du opp med 16,5% spare area og ca 2,4x minimum worst case ytelse. (som da er nesten 20% av maks ytelse)

 

Et grovt estimat jeg gjorde for en stund siden er at man ikke vil merke forskjell i en daglig bruk blind-test om random write IOPS (ved lav QD) er over 10.000. Det kan også være greit å ha i bakhodet om man setter ekstra spare area.

 

Jeg savner videre utvikling rundt SSD. Feks, raidkontrollere med funksjoner som SSDer trenger, uten funksjoner som hdder trenger... Filsystemer som er laget spesielt for SSD, osv.

 

Må innrømme at jeg ikke vet så mye om temaet, men av det jeg skjønner er det fremdeles mye uoptimalisert rundt SSDen.

Nyere RAID kontrollere tar hensyn til SSDer på en helt annen måte enn eldre. Mange gamle RAID kontrollere klarte ikke å flytte så mange IOPS som èn singel SSD og ble en flaskehals for de. De fleste nyere RAID kontrollere begrenser ikke IOPS for 1 SSD, og de fleste greie kontrollere gir 2 SSDer greit rom for IOPS. Skal man over 50-80K IOPS trenger man bedre kontrollere. Hovedkort makser ut rundt 100K IOPS (intel noe høyere med overklokking).

 

Hovedfordelen med HW RAID kontrollere er som nevnt over write buffering, read-ahead, og økt sekvensiell hastighet. Gode nyere RAID kontrollere med 6Gbps klarer 1500-2000MB/s båndbredde (eller mer). De kan også ha andre triks på lager som load balancing, write attenuation, holde hot-files i cache, etc.

 

Filsystemer for SSD er det arbeid med. De fleste SSDer lages dog som "legacy" lagring. Noen som har brutt med dette er Fusion-IO, som har laget en helt annen arkitektur og bruker egne low-level drivere. Resultatet der er latency på nivå med SATA RAM-SSDer, god skalering, og veldig god throughput.

 

EDIT: ops, fikset regnefeil med bruk av 2 %-deler på rad i spare area regningene

 

EDIT2: Her er en graf som også viser forhold mellom Overprovisjonering og write amplification i et slikt worst case (bare små random writes). Dette er også gitt ideell garbage collection, med dårlig GC metoder kan det være høyere.

Vanlig bruk ligger langt fra worst case, og gir også tid for idle GC til å jobbe så utslaget av WA på IOPS ikke blir så stort.

Endret 19. juni 2011 av GullLars

[Simen1]

Er det noen som vet hvordan denne yter i reelle ikke-Microsoft-programmer?

[GullLars]

Hvilket microsoft program testet de? Tenker du på under andre OS?

Eller er det referert til at disse var syntetiske benchmarks (med untak av PCmark som er delvis reelle mønster), og du ønsker å se reelle tester, men ikke av microsoft programmer?

Jeg støtter forslaget om en boot + launch test, og andre RL workloads, men da må RAIDet testet på samme SB system som de nye SSDene.

[icc]

Noen som vet om det er støtte for Trim på dedikerte hardware raid kontrollere?

Nei, så langt jeg vet støtter ingen dedikerte HW-RAID kort TRIM, og ingen åpne løsninger støtter TRIM for RAID arrays.

Kan ta med at 13/01 i år ble det lagt inn en patch på linux-kjernen, commit 5fc2ffe, som gir md raid1 støtte for trim. Det er forhåpentligvis ikke så alt for lenge til vi får støtte i md raid0 heller.

 

Simen1: det kunne vært morsomt å f.eks. sett en mysql-bench e.l. på ext4 med noatime, nodiratime, data=writeback og discard.

 

Bryr meg lite om pcen min bruker 5 eller 7 sekunder på å starte, det som har noe å si for meg er hvor mange sql-spørringer jeg kan behandle i sekundet.

 

Edit: det kunne også vært morsomt med en litt mer omfattende sammenligning av 1 ssd med trim og 2 i raid-0 uten trim.

Endret 19. juni 2011 av icc

[David Brown]

Hvordan er ytelsen i forhold til samme oppsett med RAID 1?

RAID 1 er speiling så det vil gå litt saktere en med kun 1 SSD

Det er kanskje tilfelle med Intel "fakeraid" raid1, men det er ikke sant med raid1 generelt. Skriving til raid1 er ofte litt tregere, fordi man må skrive to kopier av samme data - men det er søke og lesehastigheter som gjør forskjell i vanlig bruk.

 

Med software raid1 på Linux, går lesing av én fil på raid1 samme hastighet som om man hadde en enkel disk. Men dersom man skal lese to fil samtidig, noe som er ofte tilfelle når man kjører programmer eller starte systemet, leser den en fil fra hver disk - dermed får man omtrent dobbelt hastighet.

 

Og med "raid10,far" layout i software raid på Linux, får man sikkerheten av å kunne tolerere en tapt disk, samtidig som man får hastighet til raid0. Dersom man bruker HD istedenfor SSD, er det faktisk raskere enn raid0 fordi den leser mest fra de raskere blokker lengre ut på disken.

 

Det hadde vært kjekt om hardware.no hadde lært litt mer om andre systemer før de tester hardware. Det er greit nok at de fleste må leve med begrensningene av Windows, men dersom man skal skrive en artikkel om rask hardware, er det lurt å teste med flere operativsystemer til sammenligning.

[GullLars]

<snip>linux<snip>

SSD på linux fortjener en egen artikkel.

For SQL ville jeg sjekket Vertex 3 Max IOPS 128GB/256GB, om du har AMD SB850 eller Intel 67 chipset med 6Gbps porter. Med mindre du sitter på noe kraftigere enn 1Gbit ethernet eller kjører SQL forespørslene internt på maskinen burde det fjerne lagringsmedie som flaskehals, eller i alle fall for det aller meste den.

[JohnRichard]

Lese ikke alle sidene, men tror ikke dere har beskrevet risikoen ved raid 0 over flere disker?

 

Dersom du kjører raid 0 med 4 disker, vil du ikke miste alle data dersom en av diskene feiler..?