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

[Cejka Rudolf]

Dan Ohnesorg <dan na feld.cvut.cz> wrote:
> Jinak ten load se projevuje, tezko se tam prihlasuje a kdyz jsem chtel
> neco delat na databazi clenu pres php, tak jsem mel potize s tim, ze
> scripty timeoutovaly.

?!?! Hmm, hmm...

Pokud se omezim pouze na Linux a budu-li trochu konkretnejsi,
aby jsme se stale neomezovali jen na blize nespecifikovane
operacni systemy, tak:

Velikost loadu s temito problemy vubec nemusi souviset. V tomto
pripade ovsem neznam dostatek skutecnosti, ktere to mohou ovlivnit,
a rozhodnuti musim nechat na jinych lidech. Pravdepodobnost prime
souvislosti s loadem je ale rozhodne mnohem mensi, nez napriklad
ve FreeBSD.

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.

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). V tomto pripade si myslim, ze procesor nejuzsim mistem
neni, jak by si podle loadu urcite mnoho lidi myslelo. Z toho, co jsem
videl, bych se podival na (nevidel jsem iostat, systat, netstat, ani
zadny velky uptime):

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

* 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,
  proc se nikdo dlouho neznazil prekrocit 256 MB na jeden swap (to ale jen
  spekuluji). Na malych a malo zatizenych systemech to problem neni.
  Dokonce se muze nekomu i zdat, ze je v tomto smeru Linux rychlejsi nez
  mnoho jinych systemu, protoze prace s kratkymi linearnimi seznamy
  je efektivni. Jenze u stroju s velkym a skutecne pouzivanym swapem
  (viz top) je swap vysoce fragmentovan a problem je na svete. Prestava
  byt zajimavy absolutni cas jedne primitivni operace, ale mnohem
  dulezitejsi je nyni slozitost a horsi nez linearni uz snad ani byt
  nemuze.

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

--
Rudolf Cejka   (cejkar na dcse.fee.vutbr.cz;  http://www.fee.vutbr.cz/~cejkar)
Brno University of Technology, Faculty of El. Engineering and Comp. Science
Bozetechova 2, 612 66  Brno, Czech Republic