uptime... [was: Re: Redhat v ceske nemilosti?]

[Jan Kasprzak]

Cejka Rudolf wrote:
: Dam extremni protipriklad (opakuji, ze se to FreeBSD netyka): Mam
: paskovou mechaniku. Dam "mt rewind" tak, aby operace trvala rozumnou
: dobu, rekneme minimalne minutu. Po dobu trvani teto operace sice
: procesor a disky prakticky nic nedelaji, ale presto load smeruje
: k hodnote o jednicku vyssi. U nezatizeneho systemu by tedy load
: casem stoupl az blizko k jednicce. Kdyz podobnym stylem vygeneruji
: vetsi pocet takovych procesu, muzu mit load prakticky libovolne
: vysoky, a presto budou procesor, disky a pametova sbernice naprosto
: nezatizene. Za teto situace si nedovedu predstavit ani jeden rozumny
: duvod, proc by mely takoveto skripty timeoutovat. Ale mozna se
: mylim a rad se necham poucit.

	Treba prave proto, ze cekaji na disk (= nez se neco naswapuje
do pameti nebo nez se do pameti nactou prislusne buffery). Pokud pred
vami ceka na disk dalsich 600 procesu, neni timeout treba v DB serveru,
kde klient ceka na socketu po nejakou dobu) az tak nepravdepodobny.

: Nevim, jak to vidi ostatni, ale ja osobne to povazuji za jednu z hodne
: velkych chyb Linuxu, ktera mi docela komplikuje ladeni systemu na
: optimalni vykon (procentualni informace o idle a vyuziti procesoru
: jednotlivymi procesy jdou take podle plotu, ale to uz je obecny
: problem).

	Linux umi udat informace o idle time a system, user a nice time
procesoru. Idle time je 100% v poradku, muze dochazet k "chybnemu" zapocitani
behu pod prerusenim se zamaskovanym IRQ do uzivatelskeho casu procesu,
ale to si myslim, ze ladeni systemu nijak nevadi (a ziska se tim nizsi latence
preruseni, protoze se pri zakazu IRQ nemusi osetrovat, kam ten cas zapocitat).

: * Velikost pameti 256 MB RAM na 1000 procesu je dost malo a kdyz
:   uz bych neco vyzdvihoval, tak urcite prave toto: Ze zvlada
:   1000 spojeni s 256 RAM a neslozi se (je-li 1 spojeni = 1 proces).
:   Pro diskovou cache asi moc mista neni a kdyz ma tento system
:   nastartovat nejaky proces nebo nahrat stranku jakehokoli procesu
:   do pameti, aby mohl pokracovat v behu dale, muze mu to trvat
:   opravdu velmi velmi dlouho a tim by mohly vznikat i zmimnovane
:   timeouty.

	Ano, nejzajimavejsi na cele veci je, ze opravdu tohle vsechno
(>1200 procesu ve spicce) bezi na 256M RAM. ProFTPd totiz v podstate
potrebuje v pameti jen smycku okolo sendfile() coz je nejakych par
stranek.

	Jinak z vlastni zkusenosti muzu rict, ze server se behem teto
doby choval pomerne dobre co se tyce odezvy na prikazy (samozrejme pokud
prictete cas, nez se do pameti naswapuje shell, kteremu ty prikazy davate),
a pokud se ty prikazy netykaly zrovna disku, na kterych je FTP strom.

: PS: Je mi docela smutno, ze sve pochybnosti tu zatim vyjadril jen
: jeden clovek.

	Pochybnosti o cem? Ze muze na 256 M pameti a temer vyhradne s IDE disky
bezet FTP server, ktery obsluhuje 1050 uzivatelu na celkove rychlosti okolo
90 Mpbs? Nebo o tom, ze load zrovna nevyjadruje to, co vy si pod loadem
predstavujete?

-Y.

-- 
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
Mantra: "everything is a stream of bytes". Repeat until enlightened. --Linus