W dniu wtorek, 7 maja 2013 03:16:07 UTC+2 użytkownik M.M. napisał:
> W dniu wtorek, 7 maja 2013 02:47:49 UTC+2 użytkownik Stachu 'Dozzie' K. napisał:
>
> > 1. Jeste� pewny, �e to dyskowe I/O jest w�skim gard�em u ciebie?
>
> Pewny na 100% nie jestem, ale gdy mierze czasy zapytan, to nie widze
>
> innej mozliwosci.
>
>
>
>
>
> > Szcz�liwiec. Dwie trzecie roboty ju� za tob�, bo namierzenie w�skiego
>
> > gard�a to ta trudniejsza cz��.
>
> Moim zdaniem jest inaczej, 2/3 roboty, jesli nie 4/5, to optymalizacja po
>
> namierzeniu waskiego gardla.
>
>
>
>
>
> > 2. Do odci��enia dysk�w u�ywa si� cache'u w r�nych postaciach, na
>
> > przyk�ad wst�pnie przeliczonych danych w pami�ci.
>
> A jesli pamieci jest za malo, to zastanawiam sie, zeby czesciowe wyniki
>
> trzymac sie w sekwencyjnych plikach dyskowych.
>
>
>
>
>
> > Nie paprze siďż˝ na
>
> > pojedynczych blokach na dysku, bo to zbyt pracoch�onne i trudne do
>
> > zmierzenia.
>
> Nie twierdze ze trzeba paprac sie az tak niskopoziomowo aby osiganac
>
> (w miare) sekwencyjny dostep. Po prostu zapisuje sie rekord po
>
> rekordzie na dobrym systemie plikow, a system operacyjny powinien
>
> zapisac dane w sekwencyjnych blokach.
>
>

mozliwe ze przy takim w/ gardle
(jesli chodzi o zwykle pliki)
trzeba po prostu zarzucic
defragmentacje (programem
defrag czy czyms takim) - wtedy
lite sekwensyjne pliki faktycznie
powinny sie stac sekwencyjne

co do baz danych to faktycznie
pewnie moze to byc rozrzucone
i byc moze ten rozrzut odpowiada
za glowna czesc tych spowolnien