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

[Pavel Kankovsky]

On 21 Apr 2001, 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...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.

Ovsem na tom systemu, o kterem mluvime, to neni paska, ale disky (nebo
mozna obecne i/o), a tudiz je jista logika v tom, ze ostatni procesy
narazi. (Druha vec je, ze je neco spatne, kdyz proces klidne muze viset
treba minutu trvale v uninterruptible sleep.)

> 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...

"Load average" znamena trochu volne prelozeno "prumerna zatez". Slovo CPU
tam nikde nevidim. Je tedy logicke do ni nejak zahrnout i vytizeni i/o,
pripadne jinych casti systemu, bez ohledu na to, jaky na meli nazor lidi
na UCB. Na druhou stranu je naivni ocekavat, ze libovolny pokus o agregaci
zateze jednotlivych komponent do jedne skalarni hodnoty bude vzdy mit
jasnou vypovidaci hodnotu. Nejake GizmoBSD to mozna dela lepe, otazka je,
jestli se pripadna snaha o napravu opravdu vyplati, protoze osobne nevidim
jiny smysl existence l.av. nez ten, ze jeho vysoka hodnota indikuje stav,
kdy *nekde* *neco* drhne a kdy je treba to zacit zkoumat podrobneji:
jestli je v Linuxu dost jinych ciferniku, nebo ne, to je jina otazka.

> (procentualni informace o idle a vyuziti procesoru jednotlivymi
> procesy jdou take podle plotu, ale to uz je obecny problem).

Nespravne hodnoty se ukazuji predevsim u procesu, co generuji nevhodnym
zpusobem context switche -- nebo v situaci, kdy se spousta casu spotrebuje
v interruptech a ty chodi tak blbe, ze se strefuji do uplne jineho
procesu, nez kvuli kteremu ty interrupty vznikaji. Prvni problem by se dal
resit presnejsim pocitanim casu, co procesy spotrebovavaji, coz by na
dostatecne chytrem CPU melo byt celkem resitelne. V druhem pripade je to
do jiste miry inherentni architektonicky problem (nejen linuxovy), protoze
predstava, ze libovolna cinnost operacniho systemu musi mit nekoho, kdo ji
bude "financovat" (tj. na jehoz triko pujde spotreba CPU a pameti), je
ponekud mimo unixovy zpusob mysleni.

> V tomto pripade si myslim, ze procesor nejuzsim mistem neni, jak by si
> podle loadu urcite mnoho lidi myslelo.

Ne neni. A mne neco takoveho nikdy vubec nenapadlo. :)

> * Velikost pameti 256 MB RAM na 1000 procesu je dost malo a kdyz

To zalezi. Osobne bych si myslel, ze FTP demon by nemel potrebovat vic nez
100 kilo privatni pameti (i to je porad 2x vic, nez melo ZX Spectrum
a co to umelo za veci! <g>), cili dohromady by melo porad zbyt 150 mega
na vsechno ostatni.

Problem je ta diskova kes. Pro tento druh procesu ma valny smysl jen
read-ahead, pominu-li neco malo na metadata, nicmene zalezi na pomeru
pristupove doby, rychlosti prenosu z disku a rychlosti, s jakou je to
tlaceno ven pres sit, jak velky by ten read-ahead mel byt. Uvazime-li
objem prenasenych souboru, je pravdepodobne, ze nebude moc hrozit, ze by
data (nikoli metadata) kesovana jednim procesem mel moc sanci vyuzit jiny
proces. Tady to vychazi na neco kolem 100-200 kilo na proces, coz je IMHO
rozumny read-ahead jen pro ne moc rychle spojeni (musi stacit na dobu, nez
budou obslouzeny ostatni procesy, cili cca 1000x seek + nejake cteni, cili
mozna neco kolem 10 sekund, cili rychlost 10-20 kB/s)...rozhodne ne pro
lidi, co to sosaji pres TEN. :)

> * Je obecne znamo, ze v Linuxu jsou (nebo byly - o 2.4.x nemam zpravy)
>   dost spatne algoritmy pro praci se swapem. Mozna je to jeden z duvodu,

Na stroji, ktery je zatizen diskutovanym zpusobem, podle mne neni prilis
prostor, aby neco zlepsily sebelepsi algoritmy na swapovani, protoze bud
se bude swap pouzivat, pak to proste bude muset thrashovat jak blazen
(pokud nema byt pouzito planovani procesu, ktere bude vzdycky jednu
minutu bezet vybranych 100 procesu, dalsi minutu jinych 100 procesu...,
coz bude thrashovat malo, ale zvenku to nebude o moc rychlejsi), nebo se
do nej bude jen odkladat jen nepotrebny bloat bezicich procesu. Fakt, ze
je 300+ mega swapu pouzivano, ale porad jeste nezkolabovalo, svedci spis o
druhe variante, cili zbytecne nenazranosti pouzivanych programu.

>   byt zajimavy absolutni cas jedne primitivni operace, ale mnohem
>   dulezitejsi je nyni slozitost a horsi nez linearni uz snad ani byt
>   nemuze.

Ale muze... :)   (Videl jsem na vlastni oci implementaci trideni
s casovou slozitosti O(n^3). Poznamenavam, ze i zcela naivni
implementace ma slozitost pouze O(n^2).)

Nicmene to, co rikate, je trochu zavadejici.

Jestlize "primitivni operaci" myslite opravdu primitivni atomickou operaci
(napr. jedno prirazeni), pak jeji cas se vzdy povazuje za konstantni a
take se v praxi jako konstatni jevi. Ovsem to nejak nesouvisi s problemem.

Pokud "primitivni operaci" myslite napr. jedno vyhledani v nejake datove
strukture, pak pochopitelne "absolutni cas" na jeji provedeni je velicina
uzce souvisejici s casovou slozitosti teto jednotlive operace -- a
parametry popisujicimi jeji vstupni data.

Nicmene existuje jeste jedna casova slozitost, ktere se rika amortizovana,
ktera bere v uvahu (lidove receno) prumernou slozitost jedne operace
v cele posloupnosti operaci, ve kterych muze jedna napr. trvat mnohem
dele, ale preusporada zpracovavana data tak, ze ostatni probehnou radove
rychleji, cili v prumeru se to vyznamne vyplati. V pripade velke zateze
systemu muze byt rozdil mezi obycejnou a amortizovanou slozitosti vysoce
relevantni.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."