abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 13:30 | Zajímavý software

Byly uvolněny zdrojové kódy známé rogue-like hry DoomRL. Počátky hry jsou v roce 2002. Je napsána ve FreePascalu a zdrojový kód je nyní k dispozici na GitHubu pod licencí GNU GPL 2.0. Autor pracuje na nové hře Jupiter Hell, která je moderním nástupcem DoomRL a na jejíž vývoj shání peníze prostřednictvím Kickstarteru.

Blaazen | Komentářů: 0
dnes 13:15 | Pozvánky

Přijďte s námi oslavit vydání Fedory 25. Na programu budou přednášky o novinkách, diskuse, neřízený networking atd. Release Party se bude konat 16. prosince v prostorách společnosti Etnetera. Na party budou volně k dispozici také propagační materiály, nová DVD s Fedorou 25 a samozřejmě občerstvení. Přednášky budou probíhat v češtině. Pro více informací se můžete podívat na web MojeFedora.cz. Jen připomínám, že tentokrát jsme zavedli

… více »
frantisekz | Komentářů: 0
včera 16:38 | Komunita

Byly zveřejněny videozáznamy přednášek a workshopů z letošní konference OpenAlt konané 5. a 6. listopadu v Brně. K videozáznamům lze přistupovat ze stránky na SuperLectures nebo přes program konference, detaily o vybrané přednášce nebo workshopu a dále kliknutím na ikonku filmového pásu. Celkově bylo zpracováno 65 hodin z 89 přednášek a workshopů.

Ladislav Hagara | Komentářů: 0
včera 11:30 | Komunita

Bylo oznámeno, že bude proveden bezpečnostní audit zdrojových kódů open source softwaru pro implementaci virtuálních privátních sítí OpenVPN. Audit provede Matthew D. Green (blog), uznávaný kryptolog a profesor na Univerzitě Johnse Hopkinse. Auditována bude verze 2.4 (aktuálně RC 1, stabilní verze je 2.3.14). Audit bude financován společností Private Internet Access [reddit].

Ladislav Hagara | Komentářů: 4
včera 06:00 | Komunita

Na YouTube byl publikován Blender Institute Reel 2016, ani ne dvouminutový sestřih z filmů, které vznikly za posledních 10 let díky Blender Institutu. V institutu aktuálně pracují na novém filmu Agent 327. Dění kolem filmu lze sledovat na Blender Cloudu. Videoukázka Agenta 327 z června letošního roku na YouTube.

Ladislav Hagara | Komentářů: 0
včera 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 1
8.12. 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
8.12. 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 5
7.12. 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
7.12. 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 2
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 808 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Rychlost velkých Barracud v RAIDu & NFS

18.1.2009 15:19 vencas | skóre: 32
Rychlost velkých Barracud v RAIDu & NFS
Přečteno: 666×

Zdravím,

mám problémy s výkonem nových disků. Na nfs (/home) serveru, kam se připojuje (zejména) aplikační server s LTSP, jsem kvůli odcházejícímu disku v RAIDu jsem odstranil původní raid0 (strip) se 2x200Gb (celkem 400Gb) Barracudami, SATA (ne SATA II) na onboard řadiči. Místo nich jsem koupil nový řadič SATA II do PCI-X a na něj pověsil 4x700Gb Barracuda es(.2) v raid10 (celkem tedy 1.4TB). Na raidu je ext3 (interní žurnál, parametry default), server debian lenny, nfs klient ubuntu hardy.

NFSko se výměnou disků bohužel znatelně zpomalilo (takže load average občas i několik minut 20, wait 80% apod.); podle iostatu výrazně převažuje zápis (3:1 proti čtení).

  1. Proč došlo ke zpomalení? Jsou větší disky o tolik pomalejší, ještě když jsou navíc v raid10 a na SATAII?
  2. Jaké by bylo nějaké úsporné hardwarové řešení? Bohužel není tolik peněz, abych ty disky vyhodil a dal tam místo nich 4 velociraptory, ale mohl bych koupit třeba 2, ale pak by musel filesystém umět dát často používané soubory na ně a zbytek nechat na barracudách; ale umí to nějaký fs? Klientovi jsem přidal 16GB RAMky (z toho typicky cca 4GB data, zbytek cache vfs), ale není mi jasné, jestli vfs automaticky kešuje i NFSko. Paměť do NFS serveru zatím dokoupit nemůžu (má 4GB, vešlo by se 12, ale je to DDR(1) ECC registered, v současné době už dost drahé).
  3. Softwarové řešení? Nastavil jsem noatime,nodiratime (jak na nfs serveru, tak na nfs klientovi), commit=30 (ext3), zvýšil MTU na 9000 (co obě Gbit sítovky, propojené kříženým kabelem, zvládnou), dále klientovi rsize=32768,wsize=32768, nfs serveru jsem u exportu připsal wdelay. Lze fyzický zápis na NFS ještě nějak více opozdit, i na úkor konzistence? Jaký efekt by mohlo mít nasazení ext4 s delayed allocation, když je tam tolik toho zápisu? Mohlo by pomoci, kdybych dal externí žurnál na svižné 37GB U320 SCSI?
  4. Čím dalším získat relevantní informace? Zkoušel jsem bonnie++ a iozone, ale nevím moc jak tu hromadu čísel číst. Z iotopu chci zjistit, co nejvíc na ty disky píše a nějak to omezit.

Díky za jakékoliv nápady.

Odpovědi

19.1.2009 15:30 vencas | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

Tak si odpovídám sám: zdá se, že zpomalení výkonu způsobovala vypnutá write-cache u harddisků. (podle diskuse na rootu -- možná už je zastaralá?): Linux (jádro) nemá příkaz flush-cache, proto write-cache u disků implicitně zakazuje. Po použití hdparm -W1 /dev/sdc ... na všechny disky v raidu se rychlost subjektivně zásadně zvýšila.

Takhle vypadal starý dmesg:

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back

a takhle vypadá nový:

[   61.267195] sd 2:0:0:0: [sdc] 1465149168 512-byte hardware sectors (750156 MB)
[   61.423695] sd 2:0:0:0: [sdc] Write Protect is off
[   61.423805] sd 2:0:0:0: [sdc] Mode Sense: 73 00 00 08
[   61.425794] sd 2:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

Otázka je, proč se to projevilo až s novými disky? Napadá mě jen, že ty staré barracudy 7200.7 vůbec vypnutí/zapnutí cache zvenčí neumožňovaly a implicitně byla zapnutá, kdežto nové to umožňují a kernel ji vypne.

Konečně, hrozí nějaké zásadní nebezpečí, když je server na UPSce, která by ho měla po několika minutách bez proudu bezpečně vypnout? Nebo mám při výpadku proudu pustit hdparm -W0 a když naskočí zase hdparm -W1?

26.2.2009 18:22 vencas | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

Post scriptum: zkoušel jsem do toho LSI řadiče připojit starou Barracudu a write-cache měla vypnutou; zatímco na oboard SATA, jak to bylo předtím, byla bez dalšího zapnutá.

Takže je to default řadiče, že vypne cache, nikoliv disků. Nebylo mi to předtím jasné.

19.1.2009 15:36 vencas | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

Ještě jedna otázka zkušenějším: TCQ(tagged command queuing) by měl zvýšit výkon podobně jako write-cache, ale způsobem, který nezvyšuje riziko ztráty dat při výpadku proudu. Podporuje to Linux (2.6.26 v tomto případě), kde se případně dočíst o podpoře na řadičích a na diskách? Díky.

19.1.2009 23:43 frr | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

Už jste to vyřešil sám, závěr je pro mě osobně dost překvapivý a zajímavý, gratuluji a děkuji za informaci. Na SATA disk připojený přes LSI SAS řadič funguje "hdparm"? No to je geniální... ještě kdyby fungoval smartctl :-)

Snad jen pár poznámek na okraj:

Z Vašich poznámek jsem nabyl dojmu, že řadič "HP" (LSI) používáte jako tupý HBA a RAID 10 používáte nativní Linuxový softwarový (ne nějaký proprietární soft-RAID ovladač od LSI). Pokud je to tak, děláte to správně.

Ten původní SATA řadič od AMD byl obsluhován jiným driverem (něco v rámci libata nebo stand-alone driver ve "scsi low-level drivers") než Váš nový řadič, který je podle všeho osazen čipem LSI SAS z rodiny Fusion MPT (ovladač mptsas.ko?). Možná je rozdíl v zacházení s cache uvnitř disku daný právě tím. Driver LSI message/fusion býval zaháknut do vrstvy blokových zařízení, spíš než do jednotné kernelové vrstvy SCSI - to už zřejmě není pravda, ve zdrojákách je spousta odkazů na obecné linuxové SCSI struktury, takže staré časy už asi připomíná jenom samostatný adresář ovladače, mimo jednotný drivers/scsi...

Pokud se nepletu, tak SATA NCQ stejně jako SCSI/SAS/FC TCQ je mapováno na jednotný queueing SCSI požadavků linuxové SCSI vrstvy. (Aspoň doufám, že si to ovladač message/fusion dodnes nedělá sám...). Každopádně pokud se nepletu aktuální default queue depth v ovladačích LSI je tuším 128 (bacha, nejedná se zřejmě o položku CONFIG_FUSION_MAX_SGE v .config, ale spíš o podobně znějící makra v souboru mptbase.h.)

Dále si přihřeju polívčičku: zatímco Bonnie je benchmark a tester souborových systémů, já mám jednoduchý tester na sekvenční a "random access" průchodnost blokového zařízení - výsledky jsou vidět okamžitě a jsou poměrně pochopitelné:

http://www.fccps.cz/download/adv/frr/hddtest-1.0.tgz

sice to taky jede skrz blokovou cache (žádný O_DIRECT) ale dává to docela rychlý přehled o zdravotním stavu disku/řadiče/PCI, pokud víte, kolik zhruba máte čekat. Je z toho třeba na první pohled vidět Intel ICH SATA řadič nastavený do suboptimálního režimu (pokud je použit) nebo disk s vážnými problémy (kolísání sekvenční rychlosti).

Dnešní Barracudy mají příjemnou sekvenční průchodnost, ale rychlost seekování není nijak závratná - vyšší hustota záznamu zřejmě vyžaduje delší dobu ustálení po každém seeku. Nejnovější cheetahy 15k seekují nejmíň dvakrát rychleji. Každopádně dnešní Barracuda by ani v tomto ohledu neměla být znatelně horší než 3-4 roky starý disk. Spíš pozor na závadu konkrétního kusu - nápadně pomalá průchodnost jednoho disku může znamenat blížící se vadné sektory a typicky brzdí celý RAID. Pokud máte možnost otestovat disky jednotlivě (aspoň na čtení to jde i při nahozeném RAIDu), tak je trochu provětrejte.

Ohledně write-back cache: moje zkušenost je, že s vypnutou write-back keší se prakticky nedá pracovat. Pro většinu použití to není zásadní problém - vypnutí WB cache zvažte jenom v případě, že se *opravdu hodně* bojíte o svá data.

Ti LTSP klienti, jak velké soubory vyrábějí? Na maličké soubory by možná byl lepší Reiser 3...

Taky jsem měl svého času pocit, že mi za jistých okolností CFQ serializuje čtecí požadavky od více vláken, takže se mi požadavky nerozložily mezi více "spindlů" v RAIDu. Přechod na čistý FIFO scheduler ("noop") přinesl zásadní nárůst průchodnosti (lepší škálování) při paralelním přístupu více user-space vláken. (echo "noop" > /sys/block/hda/queue/scheduler). Ale to se týkalo přístupu k HW RAIDu na 24 discích - pro 4 disky ten rozdíl nemusí být výrazný. Měl jsem pocit, že když použiji ovladač pro Qlogic HBA zakompilovaný monoliticky, tak mi CFQ funguje rozumně, ale když ho zkompiluju jako modul a loadnu až za jízdy, tak se CFQ pro nově detekovaný disk chová popsaným způsobem...

[:wq]
20.1.2009 04:28 vencas | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

Díky za obsáhlou odpověď, prakticky se tím prokoušu časem a dám vědět.

Smartctl na SATA disky funguje, musíte mu ale říci, aby pro přístup použil libata, jinak se snaží jít přes scsi: hdparm -d ata /dev/sdx (rtfm). Teď na lennym to už, zdá se, není třeba, i když v manuálové stránce se o tom pořád píše.

Řadič používá modul mptsas (lspci: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS), až budu mít další SF8484->SATA kabel, zkusím připojit staré disky, jak se to zachová, jednou přes ten LSI, jednou přes původní onboard. Zkusím nezapomenout napsat.

Zdá se, že žádný disk neodchází, hdparm -Tt dává na všech zhruba stejné hodnoty. Vedle toho jsou nové, tak snad ještě... ;-)

O data se *opravdu hodně* nebojím, všechno se zálohuje a vedle toho když vypadne proud, spadnou první ti tencí klienti, kde lidi budou mít rozdělanou práci (i když server pojede přes UPS). Nerozumím tomu, proč by řadič write-cache defaultně zakazoval (to je něco podobného, jako že na těch nových Barracudách je z výroby jumper, který je třeba rozpojit, aby se povolilo 3Gb/s!! Proč není default to, co většina lidí spíš bude chtít?) Na kerneltrap jsem o NCQ/TCQ a writeback cachi teď vygooglil thread, to si ještě přečtu.

LTSP klienti vytvářejí to co tam většinou běží: firefox, openoffice, gimp; takový ten typický bordel co bývá v /home. Teď už je to bez problémů, zdálo se ale, že většina (malých) zápisů jsou historie firefoxu, cookies, nějaké tempy apod.

Díky za ten váš nástroj, to se bude hodit.

20.1.2009 10:57 frr | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

> Smartctl na SATA disky funguje, musíte mu ale říci, aby pro přístup použil libata,
> jinak se snaží jít přes scsi: smartctl -d ata /dev/sdx (rtfm).

Souhlas, switch "-d ata" je RTFM, jenomže já to vždycky dělal přes Intel ICH on-chip SATA HBA, přes ovladač z frameworku "libata". Tenhle hardware i software má pořád ve střevech nativní podporu ATA. Jak už jsem psal, ovladač Fusion MPT není součástí libata - je to stand-alone SCSI ovladač, historicky to bylo dokonce tupé blokové zařízení - proto by mě příjemně překvapilo, pokud dnes propouští ATA příkazy pro čtení SMARTu ze SATA disků, se kterými je SAS HBA taky jenom "zpětně kompatibilní" (nativní SAS je příbuznější klasickému SCSI)... tvrdíte tedy, že Vám "smartctl -d ata" funguje i na tom LSI SAS řadiči?

Upozorňuju, že smartctl umí fungovat i proti SCSI diskům, ale použité příkazy na SCSI sběrnici jsou jiné a taky struktura výpisu je úplně jiná než u ATA/SATA disků. Pokud zkusíte SCSI SMART IOCTL na SATA disk připojený přes nějaký konzervativní SCSI ovladač (bez ATA passthrough), tak smartctl nevypíše vůbec nic, protože neproleze SCSI ani ATA SMART dotaz.

Ten jumper z výroby je nastavenej na SATA150 kvůli úspoře nákladů firmy Seagate na reklamace. Pořád ještě je venku dost lidí, kteří mají SATA150 HBA kanály, a handshake se SATA300 diskem na nich někdy nefunguje spolehlivě (viděl jsem to na vlastní oči několikrát). A vzhledem k tomu, že nejnovější Barracudy 7200.11 dělají nějakých 125 MBps sekvenčně, tak ten pomalejší kabel aspoň na první pohled není taková tragédie (pokud neuvažujete přístup do cache). Na tom jumperu je otravná jediná věc: jde dost těžko ven (není pořádně za co chytit). Pořád je to menší opruz, než když třeba svého času disky Hitachi chodily nastavené na SATA150 *softwarově*, a daly se přepnout jedině softwarem na nativním SATA HBA kanálu v IDE emulaci na standardních I/O portech - takže když to člověk cpal do RAIDu, tak se na to mohl buď vykašlat, nebo disky po dvojicích / po čtveřicích připojovat do nějakého stolního PC s CD-ROM mechanikou... Hitachi do RAIDu už pár let nedáváme, takže je klid :-)

Tu WB cache může mít by default vypnutou disk (jak správně říkáte), nebo to třeba může dělat BIOS řadiče při POSTu (takže ve zdrojácích linuxového ovladače o tom nic nenajdete), údajně to může dělat i firmware SAS řadiče (do toho není vidět vůbec)...

Ten link ohledně NCQ není až tak výživný, mě osobně se líbil <A HREF="https://kerneltrap.org/mailarchive/linux-kernel/2007/7/9/113289">tenhle příspěvek</A>. Pokud jde čistě o optimalizaci řazení seeků, tak je TCQ/NCQ v disku super. V momentě kdy se IO scheduler v rámci OS snaží zohledňovat nějaká další hlediska (viz třeba CFQ), tak si s TCQ/NCQ algoritmem disku můžou "lézt do zelí". Není to černobílé. Asi jako když se snažíte nějak pokročile priorizovat TCP/IP traffic na nějakém ethernetovém portu, a o kus dál Vám to rovnostářsky ořeže cizí router do úzké WAN linky klasickou jedinou frontou... Nakonec se prostě spokojíte s tím, co Vám ukáže nějaký benchmark :-)

Pokud jsem správně pochopil z nějakých ilustrací a popisů jinde, TCQ/NCQ má oproti OS-based IO scheduleru naopak výhodu v tom, že může seeknout údajně i několikrát v rámci jedné otáčky ploten (pokud seek na blízkou sousední stopu vychází dostatečně rychlý), čímž se částečně eliminuje rotační latence - v tom případě může jako optimální vycházet jiné pořadí požadavků, než by se zdálo čistě na základě LBA adresace, kterou uplatňuje OS. Což je ale výhoda jenom ve zmíněném případě, že jediným kritériem optimalizace je co nejúspornější seekování (scheduler "noop"). Což třeba v serveru vůbec nemusí být špatná volba. CFQ je spíš pro optimalizaci doby odezvy mezi interaktivními a dávkovými úlohami na desktopu.

Mě z toho vychází, že třeba v HW RAIDu s velikou WB cache na řadiči (dneska už třeba jednotky GB) se IO scheduler RAIDu s IO schedulerem uvnitř disků vhodně doplňují. RAID ve veliké keši rovná veliký objem požadavků zhruba za sebe podle LBA adres, a disky si to doladí ve své menší keši do lokálního optima.  Zmíněná lokální optimalizace uvnitř disků totiž funguje právě jenom v blízkém okolí okamžité polohy hlavy - pokud jsou seek positions víc rozházené po celé ploše disku, optimální řazení je odhadnutelné už na základě LBA adresy. Pokud je na discích zapnutá WB cache, tak TCQ/NCQ víceméně usnadňuje plné vytížení datového kabelu k disku (diskový scheduler interně pracuje s potenciálně mnohem delší frontou požadavků, než je jeho externí TCQ/NCQ depth). Samozřejmě opět jediným kritériem v RAIDu i v disku je co nejkratší suma seek time... (žádné CFQ se nekoná).

[:wq]
20.1.2009 12:27 vencas | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

 

tvrdíte tedy, že Vám "smartctl -d ata" funguje i na tom LSI SAS řadiči?

Ne, na něm to funguje bez -d ata. (Upřímně řečeno, o tom jak spolu interaguje jádro, řadič a disk toho vím pomálu, takže všechno co píšete je moc zajímavé čtení - díky :-) ). Jo a ten raid10 je softwarový; hw raidy jsem zkoušel jen málo (a byly to asi ty levnější, i když už opravdové a ne fake-raidy) a přišlo mi, že se mizerně ovládají (nějaké utilitky co se dají pustit před bootem).

 

20.1.2009 10:03 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS
Jejda hosi, nechcete na tohle tema udelat nejakej obsirnejsi clanek?

Ja taky resim podobnou vec, tech 6 kousku Ultra 320 disku na LSI HBA radici. Zkousel jsem to merit bonnie++, ale z vysledku jsem byl magor a bonnie-to-chart se mi nepovedlo spustit. Pak jsem zkusil iozone. Na maly soubory to vsechno vzala cache (disky ani neblikly) a kdybych to mel nechat projet cely, tak se to testuje mesice.... Z ty hromady cisel jsem byl jeste "chytrejsi" nez z bonnie++.

Zkusim vyse odkazovany test.

Osobne bych uvital neco co mi vrati test HW+filesystem:
random read: xx Mbps
random write: yy Mbps
avg seek: xx ms
sequential read: xx Mbps
sequential write: yy Mbps
Zdenek

www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
20.1.2009 11:09 frr | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

Hddtest bere jenom bloková zařízení, ne prosté soubory. Pokud chcete testovat sekvenční průchodnost proti filesystému, zkuste dd, doporučuji bs=4096. Hddtest taky neposlouží statistikou "avg seek" - pokud tuhle statistiku měříte nějakým benchmarkem, tak je syntetická, a pokud jde o reálnou zátěž, tak netuším, jak ji ze systému získat (latencytop?) Hddtest umí sekvenční a čistě náhodné čtení (případně zápis, s parametrem -w  => bacha, přepíše data).

[:wq]
20.1.2009 15:30 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS
dd testuje filesystem? Vzdy jsem byl toho nazoru ze je to sekvencni cteni/zapis na blokove zarizeni. Tedky bez vlivu filesystemu. Jasne, muzu to postvat na nejaky soubor na tom filesystemu, akle to ma nulovou vypovidaci hodnotu.

Dobu seeku jsem zatim nezmeril vubec nicim. Jde mi o tech 6 disku co mam, obavam se, jestli RAID-0 nebude mit obrovsky overhead prave v tom nez vsechny disky najedou tam kam maj.

Musit tu krabici hlavne zapnout v serverovne, at to nehuci na stole.

Zdenek
www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
21.1.2009 12:55 frr | skóre: 32
Rozbalit Rozbalit vše Re: Rychlost velkých Barracud v RAIDu & NFS

> dd testuje filesystem? Jasne, muzu to postvat na nejaky soubor na tom filesystemu,
> ale to ma nulovou vypovidaci hodnotu.

Proc myslite? Kdyz hrnete data z /dev/zero do souboru nad FS, tak otestujete prave surovou sekvencni pruchodnost do filesystemu. Pokud strihate HD video, tak tento udaj ma uzitkovou hodnotu docela dobrou :-) Filesystem pridava do sekvencniho toku svoje vlastni seeky navic, takze sekvencni pruchodnost do FS bude oproti holemu blokovemu zarizeni mensi.

> Dobu seeku jsem zatim nezmeril vubec nicim.

Mam pocit, ze [ avg.seek = 1 / Tps ] : co vy na to?

Muj hddtest reportuje pocet svych read()/write() volani za sekundu. Mozna presnejsi je ale hodnota ziskana z iostatu (utilita z baliku sysstat), ten hlasi Tps na rozhrani s diskem. Pokud spustite hddtest -2 (nebo si pockate, az hddtest bez argumentu dojede do faze nahodnych pristupu), tak mate moznost pozorovat Tps pro "seek positions" generovane nahodnym generatorem. To je IMO nejobtiznejsi load, jaky se realne muze vyskytnout, treba pri zaplnenem filesystemu - pokud po disku nechcete prevazujici seekovani mezi dvema vzdalenymi partisnami, pristup na FAT FS s IO barierami apod. Hodnoty avg.seek pri nahodnem seekovani jsou dost pesimisticke :-)

> Jde mi o tech 6 disku co mam, obavam se, jestli RAID-0 nebude mit obrovsky
> overhead prave v tom nez vsechny disky najedou tam kam maj.

Obecne u stripovanych poli to berte tak, ze [seek time celeho stripe setu] == [seek time nejpomalejsiho disku]. Cili nejpomalejsi disk = uzke hrdlo. Ale plati to jenom v pripade, ze potrebujete precist nebo zapsat cely stripe set naraz - tj. typicky pri operacich s paritou, nebo obecne pri transakci vetsi nez je stripe set size.

Konkretne u RAIDu 0 se nepocita zadna parita, takze cteni a zapis se chovaji cca stejne. Pokud je transakce mensi nez stripe size (a navic zarovnana dovnitr jednotliveho stripu), tak se zapis i cteni tykaji jedineho disku, a uplatni se pouze jeho individualni seek time. Obecne se uplatni seek time tech disku, kterych se tyka konkretni transakce...

Pri cteni celeho stripe setu (nebo jenom vice stripu vedle sebe) jednotlive disky seekuji a ctou paralelne, takze seek times se nescitaji - pro dokonceni transakce je rozhodujici seek time nejpomalejsiho disku, ostatni to proste "stihly rychleji".

Nejake slozitejsi interakce mezi seek times ruznych disku necekejte - krome toho uzkeho hrdla u vetsich transakci. Ted si nejsem jistej, jestli RAID nahodou nerozebere i zapisy celych stripe setu mezi jednotlive disky. Treba kdyz Areca inicializuje pole nulama (aspon nova SASova Areca), tak nektere disky dokonci inicializaci driv a nektere pozdeji - takze zjevne na sebe navzajem "necekaji"... Pokud by se RAID takto choval i s uzitecnymi daty, tak by pri zapisu to uzke hrdlo na pomalem disku vyniklo az po zaplneni WB cache RAIDu. Tim se dostavame k tomu, ze radic RAIDu muze cachovat "drive side" nebo "host side" transakce, nebo oboje adaptivne podle potreby - ale to je myslim uz jina pohadka, navic prakticky nedokumentovana...

[:wq]

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.