Disky pod fBSD (vykon)

Cejka Rudolf cejkar at fit.vutbr.cz
Wed Dec 19 12:47:42 CET 2001


Leo Galambos wrote (2001/12/18):
> Nevite nekdo jake ma zatezove krivky filesystem fBSD, jak to vypada pod
> vinum/RAID. Staci mi idealni prutoky, abych vedel, kde je strop.

IDE nebo SCSI?

Mam docela dost testu pro IDE starych asi rok (SW/HW RAID, UDMA66/100,
jeden kanal nebo dva kanaly, queue-tagging), ale ma to jeden problem:
Vysledky nejsou zpracovane, je to jen spousta vystupu ze skriptu.
V pripade zajmu jsem to dal do ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/bench/.

Muj dojem byl takovy, ze zcela zasadni urcujici volbou jsou disky.
Zbytek uz ma pak jen minimalni vliv nebo se s tim da neco udelat
nebo naopak uz neda :-) Co se tyka idealnich prutoku, moc moudry
z toho nejsem ani dneska. Rychlost zapisu se tvarila stabilne nekde
nad 40 MB/s, ale rychlost cteni z RAIDu prapodivne kolisala.
Bud to bylo okolo 25 MB/s, nebo 45 MB/s. Udelal jsem treba 5 testu
za sebou a tri vysledky byly rychle a dva pomale, ale na cem to
zavisi, to jsem nepochopil. Delal mi to myslim SW RAID i HW RAID.

> Take by me zajimalo, zda existuji nejake ve fBSD implementovane (a
> rychlejsi)  filesystemy, nez ext. Moc by mi take pomohlo, jestli nekde
> existuji testy, jak je to s pristupovou dobou k souborum, kdyz je jich
> treba par set v adresari.

Zkousel jsem jen vytvareni a mazani pres shellovy skript. Hodne stare
testy jsem tam dal jako files.txt. Maly novy testik s DIR_HASH
jako dirhash.txt.

Co se tyka pristupove doby, podle ruznych zdroju z FreeBSD konferenci
stoji za to mit dostatecne nove jadro zkompilovane s DIR_HASH.
Jadro s DIRPREF z OpenBSD je skoro nutnosti ;-) Nekdy pred 15. listopadem
tam pridali jednu opravu a DIR_HASH uz nema ani zadny vyznamny negativni
dopad na sekvencni prohledavani, takze DIR_HASH uz je v -currentu
i v GENERIC a jedinou "nevyhodou" je vetsi spotreba pameti, ale to se
da velmi dobre menit pres sysctl.

Pokud jde jen o sklad souboru, da se uvazovat jeste o IFS v -currentu
(kde se ale zase musi vypnout kontroly pri malloc()), coz je orezane
UFS bez adresarove struktury a nazvy souboru jsou primo cisla i-uzlu,
ale funkce open() ma samozrejme trochu jinou semantiku pri vytvareni
souboru, protoze nazev predem neni znam (nezkousel jsem to, takze je
to mozna jeste trochu jinak). Je to myslene hlavne pro squid a newsy.

> Pisu totiz neco vetsiho (z casti pod fBSD) a trosku mi to zere vykon pri
> pristupu k datum, tak bych s tim chtel neco udelat...

Treba koupit nove a rychlejsi disky, misto 8k/1k bloku zkusit
16k/2k bloky, pridat vic pameti, mit nainstalovane jadro
s DIR_HASH ze zdrojaku starych maximalne mesic... Co rika iostat?

-- 
Rudolf Cejka   (cejkar at dcse.fee.vutbr.cz;  http://www.fee.vutbr.cz/~cejkar)
Brno University of Technology, Faculty of El. Engineering and Comp. Science
Bozetechova 2, 612 66  Brno, Czech Republic



More information about the Users-l mailing list