Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Pavouk106 11. 07. 2011, 16:55:29
-
Zdravím,
potřeboval bych nějaké tipy, jak testovat rychlost a odezvu při zátěži u softwarového RAID1 pole. Případně nějaký obecný postup při testování disků jako takových.
Zatím jsem používal "jen" dd, které mi souběžně zapisovalo 40 souborů o velikosti 200MB/soubor. Hodilo by se mi ale i něc, co by mi dokázalo říct, jak disk/pole v takové situaci reaguje na další podněty (čtení, zápis, hledání, ...).
Konkrétní příkaz mám zde
for i in `seq 1 40`; do `dd if=/dev/zero of=/mnt/$i count=400000 &`; done;
Vaše postřehy s RAID1 polem by taky nebyly marné. Provozuje někdo RAID1? Nebo dokonce RAID1 jako root oddíl + home? Pokud ano, můžete spustit výše uvedený kód (upravený, kde of=/cesta/kam/zapsat/40-souborů/$i) u sebe a dát mi sem nějaké výsledky (nejrychlejší a nejpomalejší zápis, čas a rychlost - na výsledek si v terminálu počkejte pár minut). Také kdyžtak uveďte něco o HW (jaké disky, SATA1/2/3, CPU, použitý FS).
Moje konkrétní postřehy teprve dávám dohromady a rád bych přidal i jinou testovací metodiku, než "primitivní" zápisy (se čtením problémy nemám, resp. nikdy jsem je nepocítil).
Předem díky
-
Zkuste se podivat na bonnie++ nebo iozone3.
https://raid.wiki.kernel.org/index.php/Performance
-
von ten dd jede rychleji s vetsima blokama, akorat pak ze zacatku zapisuje jen do pameti, to se da zmenit pomoci direct, tak ja jsem tvuj prikaz zmenil na:
for i in `seq 1 40`; do `dd if=/dev/zero of=$i count=195 bs=1M oflag=direct &`; done
a dela mi to na RAID1 pres 4 disky SATA2 Samsung 2TB HD203WI mezi 27 a 93 sekundama.
mozna zajimavejsi je cas na kontrolu RAID, tedy
echo "check" >> /sys/block/md1/md/sync_actiona pak vycist cas z dmesg
par triku:
echo 100000 > /proc/sys/dev/raid/speed_limit_minhdparm -M 254 /dev/sda ...echo "max_performance" > /sys/class/scsi_host/host?/link_power_management_policyecho 1 > /sys/block/sda/device/queue_depth ...
to posledni proste vypne NCQ a kupodivu zrychli kontrolu RAIDu, jeste jsem nevidel, ze by to nejaky benchmark vylepsovalo, nevim tedy, proc je to defaultne zapnuty :o
ja mam tak 102MB/s
-
trubicoid2: Zkusím upravený příkaz jakmile budu u svého PC (večer). TenRAID1 máš jako systémový oddíl? Byl "používaný" během testu?
Ty další tipy vyzkouším. Mám s tím problémy odjakživa a už toho začínám mít dost. Jen potřebuju přijít na to, jestli je to diskama, kernelem, systémem, mojí neschopností nebo něčim jinym...
-
RAID1 je /, pouzivany byl, ale nic zvlastniho, navic pres e-sata byl pripojeny paty disk, na kterym bezel badblocks
takze tobe to zapisuje pomaleji? ja mam na / xfs a zapnuty bariery, bez nich by to jelo kapku rychleji
mam jeste na stejnych diskach sifrovany /tmp = RAID0 + dm-crypt + xfs a vypnuty bariery a tam to je mezi 28 a 50 sekundama
navic procesor je Phenom II 4x 3.2GHz, ale zrovna ho mam v rezimu 4x 800MHz, ten procesor nebude mit na vysledky moc velkej vliv
-
Ten můj původní příkaz zapisoval souběžně 40 kusů 205MB souborů rychlostí kolem 900kB/s a šla až někam k 600kB/s (u těch posledních souborů). V praxi to znamenalo 4-5 minut...
Používáš Firefox? Jak Ti běží systém, když ve Firefoxu běžně surfuješ (tzn. pár tabů, flash reklamy, JS, Java)? Mě se zasekává i na desítky sekund. HDD LED svítí, disky chrupu a systém je kaput, dokud neprovede všechny požadavky. Když předtim spustím iotop, tak mi nahoru vyletí [md...] proces, kterej bere sám 99,99% IO. Nahoru vyletí i když spustim ten muj příkaz.
Nemonitoruješ si systém pomocí SNMP? Já v Cacti sleduju Transactions na discích (a poli) a v momentě záseku se objeví strašně moc zápisů (pokud SNMP vůbec v tu dobu odpoví sběrnýmu PC na dotaz...).
O to divnější to ale je, že na poli je zápisů 1000 a více (prostě nějaké číslo), zatímco na disky samotné, které jsou součástí pole (a tím pádem se na ně data musí zapsat), jsou zápisy jen kolem 150. Kam se teda ztratilo těch 850 a víc rozdílu?
-
no to je tedy divny 4-5 minut...
firefox nemam, je to server, ale mam firefox na notebooku, kde je taky RAID1 + mdcrypt (dva disky ha!) a nic zvlastniho se nedeje, muzu tam ten benchmark taky pustit...
SNMP nepouzivam, nejsou chyby disku v dmesg? nevyhazuje to jeden z disku z pole? co rika /proc/mdstat ?
a nemas zapnuty write-intent bitmap? to hodne nici write-performance:
http://blog.liw.fi/posts/write-intent-bitmaps/
vypni takto:
mdadm --grow --bitmap=none /dev/md0
-
Disky jsou v poli oba v pohodě, sync je ok, za posledních X měsíců nebyl jedinej trabl (teda co se vyhození disku nebo rebuildy týče).
Do dmesg se musim mrknout zase až doma. /proc/mdstat říká, že [UU] (což by mělo být oba disky ok)
Bitmap zapnutý mám, ale můžu naprosto klidně říct, že bez něj to bylo stejný (resp. nereagování systému na desítky sekund bylo stejně častý... a jestli se t zasekl na 120 nebo 130 sekund, to už mě nevytrhne).
-
no tu bitmapu urcite vypni
jeste by mohl byt problem, ze disky dlouho premysli ale pole je nevyhodi, pak by v dmesg bylo neco jako:
[478103.625483] ata4: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
[478103.625490] ata4: irq_stat 0x00000040, connection status changed
[478103.636086] ata4: hard resetting link
[478109.408129] ata4: link is slow to respond, please be patient (ready=0)
[478113.641132] ata4: COMRESET failed (errno=-16)
[478113.641142] ata4: hard resetting link
[478114.823097] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
jeste muze ukazat nejaky chyby SMART:
smartctl -a /dev/sda
no a [UU] je dobre, nicmene jeste lepe je pustit check, jak uz jsem psal a pak kouknout na /sys/block/md?/md/mismatch_cnt, kdeby mela byt nula
na notebooku to jede mezi 81 a 134 sekundama a to taky mam jen 800MHz, takze to mozna zpomaluje dmcrypt
-
jeste me tak napada, jestli mas nastaveny u disku ERC?
smartctl -l scterc /dev/sda
melo by byt:
smartctl 5.40 2010-10-16 r3189 [x86_64-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
a nastavuje se treba smartctl -l scterc,70,70 /dev/sda, ale to musis delat po kazdym startu, nebo u WD byla nejak utilitka na to WDTLER, ale zase nektery levny zeleny ne-RAIDovy WD to pro jistotu vubec nepodporuji
-
trubicoid2: Ještě jsem nevyužil všechny hacky, které jsi naposílal, ale vypnul jsem alespoň bitmap a zkusil zápis 8GB velkýho souboru (jeden celej soubor, ne hodně malých) s pomocí dd s oflag=direct.
Docela jsem čuměl - na primárních discích (WD Green 1TB v RAID1 a používané - v době testu z nich jel desktop, ale nic jsem jako uživatel při tetu nedělal) jsem dosáhnul rychlosti zápisu ~1MB/s :o
Bez oflag=direct mám rychlost zápisu a to pole cca 66MB/s (8GB v jednom souboru).
Transactions v době testu s oflag=direct jsou ale podstatně rozdílné - zápis na pole md2 žádný, ale na discích to číslo dělalo 5000 (při zápisu bez oflag=direct to je 1000 na poli a po 150 na discích)
-
ja mam taky WD Green 1TB a to WDC WD10EACS-00D, jeste s 512B sektorama a s podporou TLER, nemas ty nahodou ten novejsi s 4kB sektorama???
a pouzivas bs=1M ? a kolik mas pameti? a co souborovej system? noatime?
ja vyzkousim zapis primo na disk, to bys mohl taky udelat, vykopni jeden disk z pole a pak na nej muzes primo psat, radeji ale napred zazalohuj ...
a v dmesg ani v smartctl -a skutecne nic neni?
a write cache je zapnuta?
hdparm -W /dev/sda/dev/sda:
write-caching = 1 (on)
dd if=/dev/zero of=/dev/sda bs=1M count=800087MB/s
dd if=/dev/zero of=/dev/sda bs=1M count=8000 oflag=direct75MB/s
a jeste cteni:
dd if=/dev/sda bs=1M count=8000 of=/dev/null89MB/s
dd if=/dev/sda bs=1M count=8000 of=/dev/null iflag=direct92MB/s
-
Konečně jsem se dostal k testování.
Všechno kromě NCQ bylo ok. NCQ jsem vypnul jak jsi napsal.
ERC muj disk prej nepodporuje (říkal smartctl).
Rychlost checku pole (~50GB) byla 97MB/s
Rychlost čtení z disku (dle Tvého dd v posledním příspěvku) byla 106MB/s, když jsem přidal iflag=direct, tak 107MB/s.
Na zápis se necítím, dokud někam neuklidím data (odpojení disku od pole, test na solo disku, potom připojení, rebuild, kontrola - na to se nějak necítím, i když teoreticky vím, jak na všechno jmenovaný...).
Ještě je jeden možnej problém a to ten s 512B vs. 4kB sektory. Co jsem tak různě četl, kde se dozvim, jaký sektory mam, tak to vypadá na 512B. Filesystem nemam zarovnanej na 4kB a na pytlíku od disku o 4kB psáno je (i na nálepce na disku je cosi o Advanced format drive). O důvod víc data někam uklidit a začít odznova a pořádně...
Jinak smartctl o mých discích říká:
Device Model: WDC WD10EARS-00Y5B1
Firmware Version: 80.00A80
User Capacity: 1 000 204 886 016 bytesVíc je asi nezajímavý.
-
tak EARS ma prave 4k sektory, tim padem bys mel vse zarovnat, nova verze fdisku by to mela umet sama, ale zrejme bez zalohy a premazani vseho vcetne MBR a partition table se neobejdes
jeste muzes beze strachu otestovat write na swap partisnach, kdyz swap predtim vypnes pres swapoff -a
a zajimavy je v smartctl -a treba pending sectors nebo error log
-
Tak to vypadá, že teda vyhodim disk z RAIDu, předělam oddíly, přeleju data, udělam to samý na druhym a pak je zase dam do RAIDu...
Vlastně na tom druhym to udělam pomocí dd toho prvního, kde už oddíly budou ok a data taky, pak by se nemusel RAID rebuildit, ne?
Nemáš s tim zkušenosti? Že bych věděl do čeho jdu...
A jak si ověřit, že fdisk to nepodělal a zarovnal oddíly správně?
-
no ja bych nabootoval trebas www.sysresccd.org
jestli fdisk umi 4k sektory poznas treba podle tohoto:
fdisk -l /dev/sdaUnits = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
muj disk ma 512B sektory, tvuj by tam mel mit 4k, jestli by to tam nebylo, tak jde jeste pouzit -b 4096
pak bych vyhodil jeden disk z pole, trebas sda2
mdadm /dev/md0 -f /dev/sda2
mdadm /dev/md0 -r /dev/sda2
znicit superblok na sda2, aby se tam potom nepletl, ja to jednou neudelal a porad se mi pole zahadne rozpadalo na dve
mdadm --zero-superblock /dev/sda2
znicit MBR a partition table na sda
dd if=/dev/zero of=/dev/sda bs=4k count=64
(normalne staci smazat jen 512B, cert vi, jak to maji ty novy 4k disky zarovnany na zacatku)
udelat novy partice zarovnany na 4k
fdisk /dev/sda
udelat novy pole jen s jednim diskem
mdadm --create /dev/md1 --metadata=0.90 --level=1 --raid-devices=2 missing /dev/sda2
metadata dej 0.90, jestli chces kernel-autodetekci, teda jestli je to / a nepouzivas initrd
jinak dej metadata 1.20
naformatovat novy pole, namountovat, okopirovat vse ze staryho pole na novy
zrusit stary pole, smazat superblock na sdb2, smazat MBR a partition table na sdb2
okopirovat 4k zarovannou partition table ze sda na sdb
sfdisk -d /dev/sda | sfdisk --no-reread /dev/sdb
pridat sdb2 do pole a pole se samo zasynchronizuje
mdadm /dev/md1 -a /dev/sdb2
nastavit grub nebo co mas do MBR sda a sdb (pro jistotu) a je to
snad jsem nic nezapomnel ???
jinak urcite udelej rebuild, neeeee dd, ty dva oddily sda2 a sdb2 v RAID1 nejsou uplne stejny, lisi se tim superblokem, kterej muze byt podle verze na zacatku, na konci nebo uprostred
hodne stesti! ;)
-
fdisk -l /dev/sda mi tuším právě tvrdil, že prej 512... Tak mu to dám jako parametr při rozdělování. Resp. udělám to pomocí cfdisk, tak si to počtu u něj nápovědě ;-)
Úplně se na to těšim, to bude práce jak na kostele... Dvakrát kopírovat skoro celou velikost disků... No, o víkendu bude co dělat... :-) (vzhledem k rebuildu 900GB oddílu za 6 hodin to nebudu zkoušet v tejdnu, chci se taky někdy vyspat... :-D )
A teď konečně - musim Ti vyseknout poklonu! Díky za rady, sám bych to dával dokupy strašně dlouho (a proto jsem se do toho zatim ani nepustil). Dám sem vědět, jak dopadnu. Nejspíš po víkendu... :-)
-
aha, vono muze byt, ze ten EARS hlasi hloupe 512B misto 4k, jak pisi tady: http://www.hv23.net/tag/wd10ears
je tam taky jak pouzit fdisk a jak otestovat rychlost zapisu, aby bylo vse v poradku
s cfdiskem nevim, muzes zkusit a pak vyzkouset zapis dd, spravne zarovnany partice maji mit kolem 90MB/s, spatne kolem 26MB/s
nu a kdyz to bude dobre zarovnany, tak rebuild taky pojede rychleji...
-
Tak to ě pro změnu taky mate. Lineární zápis na pole totiž jede někde mezi, kolem 60MB/s. Ještě kouknu fdiskem, jestli to fakt nemam zarovnaný na násobky osmi, třeba náhodou jo :-) Kdyby ne, jdu do toho a přerovnam to.
Určitě bych udělal i nějaký benchmarky (jak na oddíly, tak na surovej disk) a pak sem dám zase vědět.
-
no, muze byt, ze mas nejaky partice zarovnany a nektery ne, nebo nektery lip a nektery hur
asi bys mel dosahnout zapis 90MB/s
a ten XP jumper mas nasazenej nebo ne? asi by mel byt sundanej, ten pomuze jen v pripade, ze mas jednu velkou partici, jak byva u widli zvykem
-
Ne, XP jumper nemám. Ale musím přiznat, že jsem při skládání PC naprosto vážně přemýšlel, kde seženu zapojení jumperů na master a slave :-D Všechny PC co jsem měl dřív měly jaksi jen PATA :-D Pak mi to došlo ;-)
-
Jsem zpět. Migrace RAIDu se podařila, mam nově zarovnaný oddíly, rovnou jsem si nechal rezervu ve velikosti polí (kvůli možný různý velikosti disků od jiných výrobců - kdybych musel měnit) a šlape to.
Zkoušel jsem zapisovat na disk (/dev/sdb1) i na filesystém (Ext4, namountovanej) a rychlosti byly poněkud jinačí :-P
113 na disk, 108 na správně zarovnanej FS, 92 na špatně zarovnanej FS. Zkoušeno pomocí dd, zápis 1MB, count 80000 (+-80GB). Když jsem to samý zapisoval na RAID (na správnym FS), dosáhnul jsem na 102MB/s.
Super čísla ;-) Uvidim, jak to bude vypadat během běžnýho používání...
Díky moc za pomoc
-
neni zac ;)