Autor: Piotr Pastuszka (starosta_at_inferno.mikrus.pw.edu.pl)
Data: Sun 18 Nov 2001 - 17:46:09 MET
Użytkownik "MaraBut" <martys_at_priv.onet.pl> napisał w wiadomości
news:9t8eka$fq4$1_at_news.tpi.pl...
> Piotr Pastuszka napisał :
> > > > stripe block piwinien byc jak najwiekszy [...]
>
> > > [...] testy pokazuja przyrost wydajnosci dla MNIEJSZYCH rozmiarow
> > > bloku - ale kosztem czasu dostepu.
> > > Na moim Abicie KT7-R max uzyskuje przy 16k [...]
> > > podobno Promise lepiej sobie daje rade przy duzych plikach i wynik
testu
> > > zalezy glownie od metody (rozmiaru pliku testowego).
> >
> > Zapewne.
> > Ja opieram na macierzach duzych i duzych zastosowaniach.
> > tj np gdy 10 dyskow.
> > Wtedy sciagniecie pliku 1 MB przy stripie 16 kB angazuje kazdy dysk i
to
> 6
> > razy.
> > Przy stripie 256 KB tylko 4 dyski i pozosatle 6 dyskow moze obslugiwac
> inne
> > zadanie.
> Nie jestem pewny czy dobrze zrozumialem...
> Twierdzisz, że RAID 0 moze przechowywac pliki tylko na NIEKTORYCH dyskach
> macierzy ? Nie wydaje mi sie to prawdopodobne. Idea stripingu polega
wlasnie
> na tym by zastapic transfer jednego duzego pliku z jednego nosnika,
> jednoczesnym transferem wielu malych plikow. Przyspieszenie osiaga sie
> dzieki temu, ze szybkosc transmisji
> CPU-RAM <--> interfejs HDD jest wielokrotnie wieksza niz szybkosc
> przesylania danych z nosnika do bufora HDD.
NIeprawda. Moze byc roznie. Ale generalnie ide stripingu to jest tak jak
mowisz ale tak naprawde to chodzi o to by jak najbardziej losowo rozlozyc
dostep do dyskow.
Bo przecietny dysk ni obsluguje wiecej niz 200(10k)-300(15k) odwolan./s
A czasem system wymaga 10 tysiecy odwolan /s a wiec doklada sie kolejne
dyski az uzyska sie ta wydajnosc lub stosuje soli state dysks
> Tzn. im wiecej dyskow jest zaangazowanych tym wieksze korzysci. Rozmiar
> bloku zwiazany jest natomiast z rozmiarem bufora HDD. Powinien byc taki,
by
> dysk zdazyl zapisywac / odczytywac kolejne bloki z nosnika zanim bufor sie
> napelni, co spowoduje skokowy spadek szybkosci transferu danych.
Wynikaloby
> z tego, ze im wiekszy blok - tym gorzej, bo dyski latwiej wytracic z
> synchronizmu, szczegolnie przy zapisie.
? tego nie rozumiem
dzisiaj dyski maja po 2 MB i nie rozumiem powiazania stripe 16 KB z tym co
mowisz.
Rozjasnij prosze.
A tutaj imho kwestia wydajnosci wynika z faktu ze to dyski IDE i ze
kontroler nie ma wlasnego cache.
W przypadku dyskow IDE po wyslaniu komunikatu nie mozna nic zrobic az nie
odpowie.
A wiec dzielac transfer na male kawaleczki wymuszamy czestsze dostepy do
dyskow .
> A macierz nie przyjmie/wysle nowych
> danych do procesora zanim nie zakonczy poprzedniej operacji dyskowej. Stad
> czas dostepu dla macierzy moze byc nawet gorszy niz dla pojedynczego
dysku -
> w skrajnym przypadku oczywiscie.
to tez nie do konca prawda.
bo co to jest u ciebie macierz ?
za tym kryje sie zazwyczaj jakis kontroler.
W przypadku SCSII dzialajacy asynchronicznie.
tj wysylal 20 roznych zadan a potem np odbiera odpowiedzi.
W przypadku KOntrolera IDE jest tak ze wysyla 1 zadanie i czeka na
odpowiedz. Potem wysyla drugie i czeka na odpowiedz itd.
> Nadmierne zmniejszenie rozmiaru bloku oznacza, ze dyski sa czesciej
> pozycjonowane, co pogarsza ogolna wydajnosc, chociaz nie tak znacznie, bo
> wspoczesne dyski maja duzy cache (rzedu 2MB) i stosuja algorytm "read
ahead"
> poprawiajacy odczyt na ciaglym obszarze dysku.
Ten cache takze sluzy do zapisu. a wiec nie tylko 'read ahead.'
Twoje rozumowanie ma czesciowo sens jezeli zalozy sie komus zalezy jedynie
na szybkim transferze.
Ale zazwyczaj ludziom chodzi o duzo roznych dostepow rownolegle. ( na
serwerach obslugujacych np 50+ uzytkownikow)
PitorP
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 23:21:46 MET DST