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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dan Lukes > Sent: Tuesday, October 16, 2007 12:27 PM > To: FreeBSD mailing list > Subject: Re: nizky vykon diskovych operaci ? > > [EMAIL PROTECTED] 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@freebsd.cz) > http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
