🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.sys.novell
Article #177

Re: Co obciaza serwera?

#177
From: W.Mac... Wlodzimierz Macewicz
Date: Sat, 06 Jan 1996 00:00
96 lines
4445 bytes
In article <4cjmb9$3...@okapi.ict.pwr.wroc.pl>
Jarek Lis <l...@cyber.ict.pwr.wroc.pl> wrote:
> Wlodzimierz Macewicz (W.Mac...@ia.pw.edu.pl) wrote:
> : > Wczytaj sie dokladnie w czerwone ksiazeczki. Na Netware nie ma defragmenTERA,
> : > a lenistwo programistow jest uzasadniane 'bo nie zachodzi taka potrzeba'.
> : 
> : Nie rozumiem uwagi, przeciez pisalem ze niema
> 
> Pisales, ze nie ma defragmentacji. A ja ze nie ma defragmentera.
> Byc moze juz nie nie potrafie mowic w potocznym jezyku, ale wydaje mi sie,
> ze Ty napisales, ze zjawisko fragmentacji nie ma miejsca, a ja,
> ze nie ma programu ktory by to zwalczyl.
> 

Jak nie ma defragmentera to nie ma i defragmentracji, bo niby kto (co) mialby
to robic???

> Programu nie ma. A o zjawisku czerwone ksiazeczki wypowiadaja sie w 
> sensie 'nie ma sie czym przejmowac'.
> 

Ja twierdze ze `nie ma sie czym przejmowac` co wiecej twierdze zeprzyniosloby
to wiecej szkod niz pozytku


> Oczywiscie nastetny blok z dysku. Bo on wlasnie dociera pod glowice.
> Tylko co ten blok zawiera? 
> Jesli zbiory nie sa pofragmentowane - to jest duza szansa, ze zawiera
> nastepny fragment zbioru, ktory zaraz bedzie potrzebny.

Komu?

Zalezy jak sie umowimy co do funkcji celu optymalizatora. Jesli naszym
celem jest przyspieszenie odczytu facetowi ktory zaczal sie dobierac do zbioru
to sie zgadzam, nalezy pobrac nastepny kawalek zbioru i go trzymac,
jesli natomiast optymalizujemy sredni czas oczekiwania (wszystkich chetnych)
to do bufora sciagamy losowy kawalek dysku (jesli dysk jest w pelnym
chaosie -- podefragmentowany, to bierzemy nastepny kawalek dysku (blok),
bo to najtaniej kosztuje


> A jak myslisz - po co wsadza sie tych kilkanascie MB do serwera?
> 
> : Obawiam sie ze nalezaloby przeprowadzic badania statystyczne
> : przy danym zastosowaniu serwera.
> 
chodzi zeby ja najlepiej wykorzystac

>
> 
> To pytanie - ilu z nich naprawde jednoczesnie czyta jakies pliki?
> Czy to nie jest bardziej tak, ze oni dobieraja sie do plikow
> czesto, ale zwykle niejednoczesnie?
> 

w przyrodzie nie ma pojecia jednoczesnosci, w technice tez, zadania ZAWSZE
sa realizowanie w jakiejs kolejnosci. Chodzi o to ze jest wiele zadan do
roznych zbiorow lezacych w roznych miejscach na dysku, a dysk pracuje 3 lata
wiec jak sadze osiagnal dostatecznie duzy poziom nieuporzadkowania.



> : W zastosowaniach, gdzie
> : n ludzi sieci w tym samym programie np. bazowodanowym, ktory
> : uzywa dokladnie tych samych zbiorow, wystarczy po prostu zwykly bufor
> : przy odpowiedniej wielkosci bufora na dysk, po pewnym czasie
> :  i tak beda szly tylko zapisy.
> 
> Tak. Chyba ze baza danych wielka, ale to nic nie zmienia, bo zwykle 
> charakter dostepow i tak jest losowy. Jak bedzie pofragmentowany
> plik nie gra wiekszej roli.
> 
> : > Nic tak dobrze nie dziala, jak ladnie uporzadkowany dysk. Nawet w systemach
> : > wielouzytkownikowych.
> : > 
> : Nie czuje sie przekonany
> 
> Np - przy nowoczesnych dyskach cylinder to ~0.5MB. Cylinder czyta sie 
> zgrabnie i szybko. A juz cala sciezke czytamy naraz obowiazkowo.
> A sciezka to z 50KB. Milo byloby, zeby przeczytane operacje byly uzyteczne,
> nieprawdaz?
> 
Z  punktu widzenia jednego osobnika pracujacego z serwerem nie BEDA, ale
przy wielu uzytkownikach prwadopodobienstwo bedzie tym wieksze, im
rozne sa ich punkty zainteresowan i dysk bardziej nieuporzadkowany, a wiec
typowe zastosowanie serwera plikow.

Przy jednodostepie nie da sie przewidziec czy facet zaraz nie siegnie do 
innego zbioru, ale prawie na pewno bedzie czytal nastepny kawalek tego samego.

Przy wielodostepie zadania jednego faceta sa poprzeplatane z zadaniami innych.
Jezeli bysmy mieli buforowanie dostepu do plikow (dla kazdego pliku
osobny bufor) to defragmentacja miala by sens, jesli buforujemy
sciezki to NIE MA SENSU.

Z powazaniem WM
Technical Details
Message-ID: <4clpnf$otl@gemini.coi.pw.edu.pl>
Path: mbox-mo1.pugleaf.net!unknown!not-for-mail
References: <JT.34.30E90CA2@zfja-gate.fuw.edu.pl> <4cbvfl$q05@hq.pm.waw.pl> <4ch1m0$2ca@gemini.coi.pw.edu.pl> <4chdu5$3sp@okapi.ict.pwr.wroc.pl> <4cj5js$97i@gemini.coi.pw.edu.pl> <4cjmb9$3ik@okapi.ict.pwr.wroc.pl>

Show Full Headers
Complete Article Headers
From: W.Mac...@ia.pw.edu.pl (Wlodzimierz Macewicz)
Subject: Re: Co obciaza serwera?
Date: 1996/01/06
Message-ID: <4clpnf$otl@gemini.coi.pw.edu.pl>
X-Deja-AN: 134337374
references: <JT.34.30E90CA2@zfja-gate.fuw.edu.pl> <4cbvfl$q05@hq.pm.waw.pl> <4ch1m0$2ca@gemini.coi.pw.edu.pl> <4chdu5$3sp@okapi.ict.pwr.wroc.pl> <4cj5js$97i@gemini.coi.pw.edu.pl> <4cjmb9$3ik@okapi.ict.pwr.wroc.pl>
organization: IAiIS
mime-version: 1.0
newsgroups: pl.comp.sys.novell
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit