nizky vykon diskovych operaci ?
Jan Dusatko
jan_dusatko at post.cz
Tue Oct 9 20:40:49 CEST 2007
Ahoj,
Obecne lze k propustnosti rict nasledujici. Protoze u vetsiny
disku je stale sprazeno vystavovani s otackami disku, je mozny
nasledujici hruby vypocet. Pristup ke kontinualnimu bloku dat
na disku znamena:
- vystavit hlavicku (zabere priblizne jednu otacku)
- najit zacatek dat (statisticky zabere pul otacky)
- data nacist (zabere jednu otacku)
t(bloku dat)=rotation latency+positioning time+read/write time
jinak tedy:
trand(bloku dat)= (30/RPM)+(60/RPM)+(60/RPM)
tlin(bloku dat)= (30/RPM)+(60/RPM)
TMTR (Theoretical Maximum Transfer Rate) pro nahodny pristup
pak vychazi jako:
TMTR rand=(byte na sektor*pocet sektoru na stope)/trand
TMTR (Theoretical Maximum Transfer Rate) pro linearni pristup
pak vychazi jako:
TMTR lin=(byte na sektor*pocet sektoru na stope)/tlin
V pripade RAID0 nebo jinych RAID pouzivajicich Round robin pro cteni
staci vynasobit tuto rychlost poctem datových disku a je znama informace
o celkove propustnosti diskoveho pole. Samozrejme, dalším omezenim pak
je sbernice.
Existuji algoritmy, optimalizujici pristup na datovy prostor vzhledem
ke geometrii disku, dalsi maly plus udela cache (drzi data v pameti
pro strycka Prihodu). Cache systemu a/nebo radice je naopak nevyhodou
pro velke mnozstvi databazovych serveru.
Tolik teorie ;o)
Honza
> -----Original Message-----
> From: users-l-bounces at freebsd.cz [mailto:users-l-bounces at freebsd.cz] On
> Behalf Of Dan Lukes
> Sent: Tuesday, October 16, 2007 12:27 PM
> To: FreeBSD mailing list
> Subject: Re: nizky vykon diskovych operaci ?
>
> David_Pasek at Dell.com napsal/wrote, On 10/16/07 08:02:
> >> vsiml jsem si nizkeho vykonu pri kopirovani vetsiho mnozstvi
> >> souboru (velkych i malych, obsah /var) z jednoho oddilu /var
> >> do druheho oddilu /usr
>
> > Vykon diskoveho subsystemu neni jednoduchou otazkou
>
> To neni, ale v tomhle pripade (kopirovani z tehoz disku na tentyz
> disk)
> je skoro jiste nejvetsim zroutem vykonu seekovani mezi dvema castmi
> disku. A s tim ani cache nic moc neudela. Urcite vylepseni by prineslo
> asynchronni mountunuti ciloveho svazku, protoze by se pocet seeku
> omezil. To je ale spis ad-hoc vylepseni nez reseni koncepcni.
>
> > Jedinou moznosti, jak ladit vyssi vykon disku, je
>
> No, zapomel's na solid-state disky, ktere tady nakonec nenapadne
> pripominal uz Roman. Jenze to bude realne pouzitelne az tak za par let.
>
> Dan
>
>
> --
> Dan Lukes SISAL MFF UK
> AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz
> --
> FreeBSD mailing list (users-l at freebsd.cz)
> http://www.freebsd.cz/listserv/listinfo/users-l
More information about the Users-l
mailing list