Latence disku (Re: 3ware 9550SX (rychlost sbernice?))

Středa Červenec 5 21:57:33 CEST 2006

Pavel Kankovsky wrote:
: > device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t  %b
: > sda      242     6   12.8    0.8  1019.6    28.1   76.9   0.2   15.0  10.3  14
: > sde      246    66   13.4  114.1  1036.9   731.5   13.9  69.7  546.4   7.3  93
: 
: Musím přiznat, že je to pro mne neznámý formát výstupu z iostatu, takže 
: budu místy jen hádat.
: 
	iostat 2 od Zlatka Calusice, ktery ma tu vyhodu, ze se vejde na 80
znaku. Hodnoty jsou v podstate casove diference jednotlivych hodnot
z /proc/diskstats (nebo /sys/block/*/stat).

: Zjevné je, že disky sde až sdh jsou oproti sda až sdd výrazně vytížené
: krátkými zápisovými operacemi,

	Presne tak.

: [...] Ty disky se zdají být
: poměrně intenzívně vytížené (viz %b),

	Ano, to je prave rozdil proti stare konfiguraci - novy radic
zda se umi mit vic operaci v behu zaraz, cili %b se u vice disku zaraz
blizi 100% (a vysledkem je vyssi celkova propustnost, ale bohuzel take
latence).

: ale zdá se, že vyřizování operací
: probíhá probíhá poměrně svižně (viz svc_t, to by měl být průměrný čas v ms
: potřebný na zpracování jedné operace).

	Ano, svc_t je v norme.

: Zdá se, že problém je v tom, že
: disky prostě nestíhají a požadavky se hromadí ve frontě (viz queue).

	No, to queue nemusi byt tim ze disky nestihaji, ale ze je treba
nejake vynucene poradi operaci, ne? Nebo to se projevi tak, ze ty "cekajici"
pozadavky ani nejsou ve fronte?

: Zátěž pro čtení je na všech discích zhruba stejná. To FTP, nebo co to je, 
: je rozložené přes všechny disky?

	Ano, FTP server je RAID-5 oblast pres vsech 8 disku, zatimco
/var je RAID 1+0 pres sde-sdh.

: Je divné, že to přestalo stíhat při přechodu na (aspoň papírově) lepší 
: hardware, ale vypadá to, že to prostě narazilo na hranice jeho možností.

	No, nerekl bych. Statistiky qmailu rikaji, ze stroj byl schopen
poslat >4000 jednotlivych zprav za 5 minut, zatimco ted jsou to radove
stovky. svc_t starych disku byla zhruba stejna, nove disky navic maji
umet NCQ a maji vyssi prenosovou rychlost. Rozlozeni disku je stejne
(FTP server vetsi cast ze vsech 8 disku, /var posledni ctyri disky
jako RAID 1+0). Novy radic je PCI 64/66, stary byl 33/66. Novy ma tusim
128M cache, stary mel 32. Ten novy HW je fakt rychlejsi nez byl ten puvodni,
a i predbezne testy ukazuji, ze max. rychlost FTP serveru se taky zvysila.

: Je možné, že to bylo na hraně už před tím (z grafů na webu se toho bohužel
: moc poznat nedá, protože pár extrémních špiček učinilo ze všeho ostatního
: šum u nuly),

	Je treba rozkliknout grafy jednotlivych disku na
http://www.linux.cz/stats/mrtg-rrd/hdd/
- tam ty spicky nezpusobily takove problemy.

: ale že zápisové operace byly předtím preferovány (řadičem?
: disky? rozhodně by řekl, že nějakým příliš "inteligentním" hardwarem) víc
: než nyní.

	Moje vysvetleni je, ze za to muze NCQ (cili firmware disku)
nebo podobny mechanismus v radici (cili firmware radice), ktery naopak
nepozna, ktery zapis je cachovatelny (a tedy muze pockat) a na ktery naopak
OS ceka (commit blok zurnalu a podobne). Hmm, vi nekdo, jestli vubec
se tato informace ("na tento zapis nekdo ceka, necachovat!") ma sanci
dostat od filesystemu az k disku?

: Já bych osobně zkusil /var strčit na disk, o který se nebude s nikým
: přetahovat.

	Takovy nemam. Jeste jsem zkousel jestli neni problem v RAID 1+0
- pomoci "set faulty" jsem z toho udelal jen RAID-0 - ale nepomohlo.
Navic RAID 1+0 fungoval i na starem systemu.

: Možná by také pomohlo, kdyby se nějak (nevím jak, u SCSI a FC
: to tradičně býval parametr driveru) omezil počet operací, co se najednou
: posílají do řadiče a do disků, aby nedostávali tolik možností si požadavky 
: reorganizovat podle svého mdlého rozumu.

	Jo, takhle nejak jsem si to taky predstavoval. Jeste jsem hledal,
a nasel jsem tento zajimavy dva roky stary mail (google://linux+3ware+latency):

http://www.uwsg.iu.edu/hypermail/linux/kernel/0409.0/1330.html

pise se tam, ze kdysi mel radic delku fronty vetsi nez nr_requests
daneho zarizeni, cili se vubec nemohl projevit I/O scheduler, protoze
radic sezral vsechny pozadavky, a fronta mela vzdy delku max. 1.
No a ja jsem se podival do nastaveni radice (v mem pripade 
/sys/devices/pci0000:00/0000:00:0b.0/0000:01:03.0/host0/target*/*/queue_depth
a ejhle, bylo tam 256, zatimco /sys/block/sd*/queue/nr_requests
je standardnich 128. Cili se zda, ze prestoze jde o problem dva roky
stary, stale je aktualni. Akoratze vetsina lidi asi provozuje 3ware
v konfiguraci, kde se to nepozna (na jeden SCSI target se nemichaji
pozadavky od vice filesystemu). A zrejme vetsi cache noveho radice
ve spojeni s dalsi frontou (NCQ) na urovni disku zpusobily problem.
Kdyz jsem nastavil u sda-sdh queue_depth na 4, tak mam uz propustnost
1000 zprav za 5 minut, coz je sice 4x mene nez driv, ale jde to. Jeste
tam zkusim dat 1.

	Ad qmail: problem je v qmail-send - pomoci strace se zda,
ze se to vzdycky zadrhne na fsync(), cili skutecne na cekani na nejakou
zapisovou operaci. Coz uz umozni napsat si testovaci programek, ktery neco
malo zapise, zavola fsync(), a bude merit jak dlouho to trva. Snad se
k tomu v patek dostanu.

	Jeste jsem zrejme par procent usetril pomoci noatime.

	Dalsi mozne urychleni muze byt v tom, ze bych k tomu radici
koupil baterku, cimz bych umoznil tech 128M mit jako write-back cache.

	Omlouvam se za neutridene informace, snad jsem napsal vsechno
co k tomu vim. Pokud se merenim ukaze, ze problem je opravdu v queue_depth,
napisu do LKML a asi i poslu bugreport 3ware (i kdyz ted kdyz je koupili AMCC,
tak kdovi jak to s jejich podporou uzivatelu bude - predtim to bylo docela
dobre).

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> I will never go to meetings again because I think  face to face meetings <
> are the biggest waste of time you can ever have.        --Linus Torvalds <