Software-RAID 0,1,5,6,10 - srovnání rychlostí

12.9.2007 19:53 | Přečteno: 11815× | Linux |

Vzájemné porovnání rychlostí čtení a zápisu na Linux Software-RAID level 0,1,5,6 a 10.

Linux Software-RAID využívám v distribuci Debian na serverech už několik let. Při přechodu ze Sarge na Etch jsem zaznamenal v souboru /usr/share/doc/mdadm/RAID5_versus_RAID10.txt.gz výzvu k nepoužívání RAID5 od "Art S. Kagel". Výzva je dostupná i na Internetu, případné další informace se lze dočíst na stránkách iniciativy BAARF. Tento zápisek není na téma zmíněné výzvy. V rámci studování dané problematiky jsem chtěl vědět, jak je to skutečně se vzájemným porovnáním rychlostí jednotlivých typů Software-RAID. A tak jsem v rámci instalace dalšího serveru provedl i test, jehož výsledek prezentuji níže.

Konfigurace testovacího PC

HP Proliant ML110 G4, 1GB RAM, 3xSATA 250GB HDD, 1xSATA 160GB HDD, CD-ROM IDE.

Live distribuce (R)ecovery (I)s (P)ossible verze 2.9 nabootovaná z USB klíčenky (jen CLI verze s plnou kopií do RAM a následným odpojením USB klíčenky).

uname -a

Linux RIPLinux 2.6.21 #4 Fri Apr 27 02:58:12 UTC 2007 i686 GNU/Linux

cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Intel(R) Pentium(R) D CPU 2.80GHz
stepping        : 4
cpu MHz         : 2793.289
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm
bogomips        : 5591.00
clflush size    : 64

lspci

00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub (rev c0)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01)
00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)

for i in a b c d; do hdparm -i /dev/sd$i | grep -v "^$"; done

/dev/sda:
 Model=ST3250624AS                             , FwRev=  3.AJJ , SerialNo=            9ND0T8AV
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=disabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 * signifies the current active mode
/dev/sdb:
 Model=ST3250624AS                             , FwRev=  3.AJJ , SerialNo=            9ND0JCE5
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=disabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 * signifies the current active mode
/dev/sdc:
 Model=ST3250624AS                             , FwRev=  3.AJJ , SerialNo=            9ND0R5D2
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=disabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 * signifies the current active mode
/dev/sdd:
 Model=ST3160812AS                             , FwRev=  3.AJJ , SerialNo=            4LS1D47P
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=disabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 * signifies the current active mode

Na všech HDD byly vytvořeny dva primární oddíly pomocí programu fdisk, první o velikosti 100MB typ 83, druhý o velikosti 10240MB typ fd.

Provedení testu

Na testovací PC se přistupovalo přes ssh. V průběhu provádění testů nebyly na testovacím PC vykonávány jiné programy, neběžel cron, syslog či jiné služby.

Nejdříve bylo vžy zrušeno předchozí RAID pole pomocí příkazu:

mdadm -S /dev/md0

Měřená RAID pole pro jednotlivé testy byla vytvářena následovnými příkazy:

mdadm --create -l0 -n2 /dev/md0 /dev/sda2 /dev/sdb2
mdadm --create -l0 -n2 /dev/md0 /dev/sdc2 /dev/sdd2
mdadm --create -l1 -n2 /dev/md0 /dev/sda2 /dev/sdb2
mdadm --create -l1 -n2 /dev/md0 /dev/sdc2 /dev/sdd2
mdadm --create -l5 -n3 /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2
mdadm --create -l5 -n4 /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm --create -l6 -n4 /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm --create -l10 -n4 -pn2 /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

Po vytvoření pole bylo bylo počkáno na jeho plnou obnovu (viz /proc/mdstat) a následně byl provedeno měření rychlosti čtení/zápisu. Nejdříve příkazem:

hdparm -t /dev/md0

A poté dvojím spuštěním přímého zápisu/čtení nulových dat na/z pole pomocí příkazu dd:

# write
dd if=/dev/zero of=/dev/md0 bs=4096k count=10
# read
dd if=/dev/md0 of=/dev/null bs=4096k count=10

Do tabulky byly zapsány výsledky až druhého spuštění příkazů dd (u RAID polí byly vždy o něco nižší, u samostatných disků byly naopak vždy o něco vyšší). V prvním kole byl test pomocí dd prováděn s objemem zapisovaných/čtených dat 40MB. Po sepsání výsledků do tabulky jsem se ještě rozhodl provést stejný test s objemem zapisovaných/čtených dat 1GB (count=250).

Výsledky měření

Výsledky pro 40MB

Výsledky pro 1GB

Graf rychlostí čtení/zápisu

Závěr

Měření neodpovídalo (a ani se nesnažilo simulovat) reálnému provozu, měřil se pouze zápis/čtení velkých a hlavně spojitých oblastí. V reálném provozu dochází ke čtení/zápisu menších porcí dat a to na různá místa disku. Přesto se z něj, podle mne, dají vyvodit určité závěry.

RAID0 (jak se všeobecně očekává) urychlyje zápis i čtení. A to zápis až 3x (překvapivě, v reálném provozu to bude IMHO nižší), čtení cca 1,5x.

RAID1 je při čtení mírně pomalejší než přímý přístup na disk (režije RAID) ale urychluje zápis cca 1,5x

U RAID5 se zdá, že čím více disků tím lépe (i když v tom možná větší roli hrají násobky 2). V testované 4 diskové konfiguraci dokonce vykazuje nerychlejší čtení a zápis srovnatelný s RAID0.

RAID6 je oproti RAID10 mírně pomalejší při zápisu a stejně rychlý při čtení. Oproti RAID10 však nabízí odolnost proti poruše dvou disků.

       

Obrázky

Komentáře

[Michal Fecko]

RAID5 (4d) rocks . ja som presiel na raid1 pri 2x160G SATA a subjektivne citim zrychlenie pri citani aj zapise.

[Michal Kubeček]

RAID1 je při čtení mírně pomalejší než přímý přístup na disk (režije RAID) ale urychluje zápis cca 1,5x

Napadá někoho, čím by mohl být tern rychlejší zápis? Vždyť se stejně musejí zapsat všechna data na každý z disků… Co se čtení týká, problémem je tu algoritmus volby disku v linuxové implementaci: volí disk podle toho, ze kterého se naposledy četlo nejblíže místu, ze kterého se má číst teď. To je sice výhodné pro přístupovou dobu u náhodného čtení krátkých bloků, ale nevhodné pro dlouhý souvislý blok.

[xvasek]

Moc pěkné. Ještě by mě zajímalo, jak je to s rychlostí v degradovaném režimu. Yenya kdysi psal, že degradovaný RAID5 je tragicky pomalý, tak z toho mám od té doby strach.

[Dan Ohnesorg]

Tragicky pomale je to pokud bezi obnova pole. Dokud je to jen degradovane, tak je to jeste v pohode.

Opet se potvrzuji vysledky RAID1, cteni je stejne rychle jako pri cteni z jednoho disku. Podle me je to ale spatne, prece muzu cist ze dvou disku, tak musi byt rychlost cteni srovnatelna s RAID0. Vi nekdo proc to je? Proste budu cist z disku A blok N z disku B blok N+1. Stejne jako to dela RAID0.

[Ritchie]

Takhle to fungovat nemůže. Ve většině případů byste nezískal nic, neboť po přečtení N-tého bloku na první disku byste čekal, až se N+2 blok dostane pod hlavičku prvního disku. Během neužitečného otáčení plotny by se mohl číst N+1 blok opět z prvního disku, takže číst N+1 blok z druhého disku je zbytečné plýtvání zdroji. Mnohem lepší mně přijde, že pokud k poli přistupují dva konkurenční procesy, tak každý si čte ze „svého“ disku. Ušetří se tím spoustu času, kdy by se musely hlavičky přemisťovat tam a zpět a čekalo by se na správné otočení plotny.

[Michal Kubeček]

Vím. Už jsem to tu psal dvakrát, z toho jednou přímo v této diskusi.

[trekker.dk]

Tragicky pomale je to pokud bezi obnova pole. Dokud je to jen degradovane, tak je to jeste v pohode.

Pochopitelně... Když je to jen degradované, tak se ty xory počítají jenom při čtení/zápisu. Když běží obnova pole, tak se počítají pořád, dokud se obnova nedokončí ... tedy nepřetržitě se vytěžuje procesor i všechny disky v tom poli - to se projevit musí.

[Ritchie]

Není mně příliš jasné, jak může být RAID 5 / tři disky rychlejší při čtení než RAID 0 / dva disky. Dokáže to někdo vysvětlit? Předpokládám totiž, že u každého disku fyzicky proteče pod hlavičkami disků o třetinu více dat, takže ve výsledku by měla být rychlost stejná.

Zápisy na disky mně přijdou docela pomalé. Čím to? Na RAID 5/LVM/XFS přes tři 250 GB SATA disky se dostanu při zápisu 1 GB na rychlost 85 MB/s.

[Marián André]

Zápisy na disky mně přijdou docela pomalé. Čím to? Na RAID 5/LVM/XFS přes tři 250 GB SATA disky se dostanu při zápisu 1 GB na rychlost 85 MB/s.

Povedal by som, že je to hlavne réžiou RAID5+LVM. Skutočne je prekvapivý výkon RAID5 nad 4 diskami - v praxi pozorujem pri RAID5 nad troma diskami skôr opak - citeľné spomalenie oproti RAID1.

[Ritchie]

Nemyslel jsem rychlost svého pole, ta je podle mého názoru zcela odpovídající, ale rychlost pole uváděnou v zápisku, která je podezřele nízká. Omlouvám se, že jsem se nepřesně vyjádřil.

[MartinT]

Zápisek jsem psal až z poznámek, samotný test byl dělán dříve, takže nemohu ty čísla ověřit (server už je nasazen). Výsledky jsem ukládal přímo z CLI přesměrováním výstupu druhé dvojice dd příkazů (via tee). A co si tak pamatuji, nikde nebyly hodnoty první dvojice dd "výrazně" odlišné od jejich druhého spuštění.

Vlivy paralelním zatížením systému něčím jiným lze IMHO taky vyloučit. Jediný daemon co tam běžel bylo pouze ssh a pump. Ta distribuce R.I.P. je záchranná a sama o sobě nic nespouští, nemountuje disky a byla nebyla použita verze s GUI.

Pokud je chyba, tak v následném zpracování dat. Mohl jsem špatně přepsat hodnoty z logu do tabulky a mohl jsem se dopustit chyby při seskupování údajů pro graf. Ale to by se asi poznalo konkrétně už z těch čísel.

A pokud jde o absolutní hodnoty rychlostí, může to být IMHO více věcmi. Můžete mít rychlejší disky, jinou cache, propustnější sběrnici, lepší SATA řadič .. .. . Prostě jiné železo. Právě proto vypisuji i údaje o PC na kterém jsem to testoval. Mne kupříkladu udivilo, že ten 160GB disk je "rychlejší" než ty 250GB (cca o 15%). A to má podle hdparm poloviční cache.

[alkoholik]

Uz to tu bylo milionkrat. Nepouzivejte XFS nad sw RAID5!

[Ritchie]

Děkuji za vaši reakci, ale já s výkonem XFS nad RAID 5 nemám sebemenší problém! Máte snad informace, že problémy s cache buffer size se týkají i aktuálních jader? Já jsem takové nenašel.

[Zdeněk Štěpánek]

Skvele srovnani, bohuzel jsem se nikdy nedostal ke stroji kde bych mel 4 stejne disky na hrani. Nejlepsi co mam k dispozici je 3x 15kot/s U160 a 3x 10kot/s U320. Ackoliv je radic U160 (vse na jednom kanalu), tak ty 10kot/s disky jsou citelne rychlejsi (hdparm to tvrdi...), netusim proc, jsou vicemene stejne stare.

Zdenek

[Jiri Bajer]

A jakou maji ty disky kapacitu/geometrii? Pocet ploten hraje vetsi roli, nez on-disk cache nebo max. rychlost radice. Pokud si dobre vzpominam, tak v polich od Hitachi byly doporucovany 36GB/15k disky oproti 72GB/10k prave kvuli rychlosti, 143GB/10k na tom byly jeste hur. Zkusil bych se podivat do specifikaci od vyrobce na fyzickej pocet ploten (logicky CHS si firmware vymejsli, takze nema zadnou vypovidaci hodnotu). Schvalne, zkus sem postnout vysledky...

[diverman]

Jeste k tomu dd. Nema smysl zapisovat 4MB nebo 1GB fajly. Ty se vlezou cele do RAM. Zapisuj treba 50GB soubor, at eliminujes vlivy RAM.

[MartinT]

Nemůžu souhlasit. Při dd přímo na diskovou oblast se IMHO vynechává jakákoli cache v RAM. Potvrdil mi to i výstup příkazu free občas spuštěného mezi jednotlivými testy (když jsem čekal na synchronizaci nově vytvořeného pole). Trvale ukazoval obsazeno okolo 80MB (a to i při testech 1GB)

Jediná cache která IMHO měla vliv na test byly cache v HDD (16MB u 250GB disků, 8MB u 160GB disku). A i to byl jeden z důvodů pro druhé kolo testů (s 1GB).

U druhého kola jsem zvažoval jak velká data zapisovat. Napoprvé jsem zkusil 40GB, ale vzhledem k tomu, že to trvalo poměrně dlouho a testů bylo taky dost, rozhodl jsem se pro 1GB.

[Karel]

No, s tou cache bych se hádal ;)
Dva po sobě puštěné testy:
[root@neuberk dev]# dd if=/dev/md3 of=/dev/null bs=16k count=40000 skip=10000
40000+0 records in
40000+0 records out
655360000 bytes (655 MB) copied, 6.9944 s, 93.7 MB/s
[root@neuberk dev]# dd if=/dev/md3 of=/dev/null bs=16k count=40000 skip=10000
40000+0 records in
40000+0 records out
655360000 bytes (655 MB) copied, 0.226366 s, 2.9 GB/s

[Michal]

Kdepak jsou vysledky RAID0 slozeneho ze 3 resp. 4 disku? :)

[MartinT]

Nejsou. Nepoužívám, tak mne to ani nezajímalo (a nezajímá).

[Zdeněk Štěpánek]

Me prekvapuje tech 30Gb u RAID5 (4d). U bezneho reseni s tremi disky ziskam 2/3 celkove kapacity, tak jak u 4 disku ziskam 3/4?

Zdenek

[Michal Kubeček]

Úplně stejně. U RAID 4 byste měl tři datové disky a jeden paritní, RAID 5 se liší jen tím, že parity nejsou všechny na jednom disku, ale jsou mezi ně rozložené. Obecně u RAID 5 dostanete velikost (n-1)s, kde n je počet (non-spare) disků a s velikost jednoho.

P.S.: je to 30 GB, ne 30 Gb, to je dost podstatný rozdíl.

[Mortal]

Oproti RAID10 však nabízí odolnost proti poruše dvou disků.

raid10 je take odolny proti poruse dvou disku (pokud se porouchaji ty spravne)
tak na 50% je odolny na 50% neni :)

[MartinT]

Asi jsem měl napsat: "Oproti RAID10 však nabízí 100% odolnost proti poruše dvou disků." .

Raid10 je taky "částečně" odolný na výpadek druhého disku, ale nesmí se porouchat jeden konrétní z těch tří zbylých, takže 66% ?.

[peto]

No a teraz by si mal urobit presne tie iste testy s poriadnym HW radicom, nech to mame s cim porovnat .

[MartinT]

Tam kde je HW RAID už nedělám SW RAID, takže nejsou data. Ale vyhrabal jsem něco z poznámek: server HP Proliant ML350 G5 s 4x160 SATA HDD 7.2k, řadič je "RAID bus controller: Hewlett-Packard Company Smart Array E200i (SAS Controller)" - v linuxu /dev/cciss/c?d?p? (IMHO to není "pořádný HW raid" jak píšete vy). Nejdříve na něm byl (nějakým omylem) udělán sw raid10 a nějakou dobu tak i jel. Když jsem jej pak předělával na hw RAID1+0 udělal jsem si test zápisu pomocí dd podobně jako tady v tom zápisku, ale jen s 40MB. Zápis/čtení na sw RAID10 bylo 22,5/127 MB/s, na hw RAID1+0 to bylo 13,3/139 MB/s. Zápisy na samostatné disky byly cca 11,7MB/s a čtení ze samostatných disků cca 55MB/s.