[OT] Procesory intel (do PC)

Pátek Březen 16 10:14:40 CET 2012

Děkuji za vysvětlení, ale ještě mi není jasné, top průběžně sbírá data a 
udělá průměr za časové období, takže je pouštěn častěji než jednou za pár 
vteřin, to si myslím že nebude odhozen do swapu, toto byly nemoci prvních 
swapovacích algoritmů. Na správu používám ssh a screen. To že je tam to S, 
tak ikdyž nějak sbírá průběžně data, nevím jak často, ale za 2 měsíce sežral 
půl hodiny strojového času.

root      2819  0.0  0.0   2424  1056 pts/0    Ss+  Jan22  39:28 top -d 5
root     27217  0.0  0.0   4268   700 pts/21   S+   10:02   0:00 grep top
root     31248  0.3  0.1  37536  5136 pts/12   Sl+  Jan24 251:45 iftop

S    Interruptible sleep (waiting for an event to complete)
s    is a session leader
l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
+    is in the foreground process group

----- Původní zpráva ----- 
Od: "Pavel Troller" <patrol na sinus.cz>

Zdravím,
  mám obavu, že to je proto, že je v danou chvíli odswapován, tedy na ten
disk čeká :-). Právě proto, že "popobíhá" jen jednou za 3 sekundy, je 
lákavým
cílem na odswapování - jeho kód neběží příliš často a tedy jej ten LRU
swapovací algoritmus vyhodí z paměti, no a pak už je to jasné. A jakmile se
zase do paměti dostane, rychle dožene, co zameškal :-). Případně může být
odswapováno něco, co potřebuje k tomu, aby běžel - např. grafický terminál,
pokud to děláte z grafického prostředí. To je mimochodem jeden z důvodů, 
proč
jsem navyklý čistě textové operace (např. i odpovídání na tento mail v 
muttu)
dělat v klasické textové consoli. V případě velkého nedostatku paměti a
polmrtvého systému z důvodu swapování je výrazně responsivnější.
  Zdraví Pavel

> Ještě se vrátím k tématu, neboť podle níže uvedeného nechápu, proč když 
> mám
> puštěný top, který se přehrabuje jen v paměti, při takovém vysokém čísle
> čekání na IO (30-70), občerství stránku třeba jen jednou za půl minuty,
> místo jednou za 3 vteřiny? Je to tím, že ostatní IO operace jsou zdrženy
> těmi diskovými? Podotýkám, že občas se stane - ne vždy, že po takovém
> delším čekání na refresh topu se najednou ukáže "animace" tak 5-10fps
> stránek z topu.
>
>
> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>
>
> Zdravím,
>  ano, přesně tak. Pokud úloha čeká na jakékoliv I/O (disk, klávesnici,
> vykreslení graf. prvku pomocí GPU atd.), prostě OS pustí ty, co běžet 
> mohou.
> Čili běží-li nějaký "žrout CPU" s minimálním I/O, dostane maximum výkonu
> v okamžicích, kdy ostatní úlohy musí čekat. Kdyby tam takový "žrout" 
> nebyl,
> dostane CPU Idle task, který je využije k fyzickému usnutí a snížení
> spotřeby. Tehdy bude nenulový iowait. Pokud budou CPU využity i tehdy, kdy
> nějaké úlohy čekají na I/O, bude iowait 0.
>  Zdraví Pavel
>
>> Ano, teplota cpu je nízká, prostě čeká. Takže kdybych tam měl nějaký
>> zatěžovací program, který vůbec nepotřebuje disk a ramky mu stačí pár
>> desítek bajtů, v pohodě by při takovém čekání na disk 70% (jen jedno cpu)
>> a
>> vytížení ostatními aplikacemi 30% (tedy idle=0), si vzal těch 70% výkonu,
>> co stráví cpu čekáním na disk? Takže čekání na disk bude v tomto případě
>> 0%, 70% si vezme zatěžovací program a 30% aplikace, které čekají na data 
>> z
>> disku?
>>
>> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>>
>>
>> Zdravím,
>>
>>> No mám to hlavně vypozorováno - na linuxu ale týká se to úplně stejně i
>>> woken, taky se extrémně zpomalí když se moc hrabe na disk.
>>
>> To samozřejmě ano. Ale není to proto, že by CPU čekaly na disk - v 
>> takovém
>> případě si CPU spokojeně pochrupávají v idle tasku :-). Uživatelsky se to
>> ale může jevit, že na ten disk čekají.
>>
>>>
>>> Když pustím top při vytíženém disku, tak (jen jeden) cpu čeká třeba z 
>>> 70%
>>> (stav wait), zbytek 30% něco dělá a idle je zhruba nula. Jakmile
>>> přestanou
>>> diskové operace, je idle (třeba) 20%. Pokud to samé jede na dvojjádru,
>>> tak
>>> máme k dispozici 200%, takže top ukazuje idle v tomto případě 200-80-70
>>> (tj. 50%) a systém má svižné odezvy. S dvoujádrem mám ale zkušenosti jen
>>> ve
>>> virtualizovaném stroji.
>>
>> Aha, vy myslíte stav iowait. Nu, název toho stavu je poněkud matoucí.
>> Tento
>> stav neznamená, že cpu aktuálně na něco čeká, ale, cituji definici,
>> "... The actual definition of %iowait is the percentage of the time that
>> the
>> system was idle and at least one process was waiting for disk IO to
>> finish".
>> Čili, měří to situaci, kdyby systém mohl něco dělat, kdyby měl rychlejší
>> disky. Nicméně, ano, z uživatelského hlediska se může zdát, že ty CPU
>> skutečně
>> čekají - ovšem programátorsky je v tom, jistě netřeba vysvětlovat, velký
>> rozdíl :-).
>>
>>>
>>> podotýkám, že při wait 70% se s takovým systémem prakticky nedá dělat a 
>>> i
>>> ten top hodí stránku jednou za čtvrt minuty. Většinou se toto děje když
>>> swapuje.
>>>
>>
>> Zcela logické. Pokud se swapuje, diskové buffery a fronty se zaplní
>> takovou
>> šňůrou požadavků, že prakticky každá úloha, která občas musí hrábnout na
>> disk
>> pro běžná data, třeba minutu čeká, než se na ni dostane. Pokud navíc jí
>> byla
>> zabavena RAM, musí čekat i na to, až ji dostane zpátky :-). Ale pokud
>> byste
>> měřil teplotu/spotřebu CPU, bude překvapivě nízká a tyto budou většinu
>> času
>> trávit v nejhlubším možném spánku :-).
>>
>> Zdraví Pavel
>>
>>
>>>
>>> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>>>
>>>
>>> Zdravím,
>>>  chtěl jsem se zeptat, zda níže popisované chování je skutečně
>>> implementováno
>>> v nějakém OS, nebo zda to je jen určité zjednodušení a přiblížení
>>> laickému
>>> čtenáři. Dle svých znalostí mnou používaných OS (preemptivní Unixového
>>> typu)
>>> tomu tak totiž není.
>>>  V obecném víceúlohovém OS preemptivního typu jsou v zásadě možné 4 
>>> stavy
>>> úloh: běžící, připravená, čekající a pozastavená.
>>>  V takovém OS může teoreticky běžet (tj. být ve stavu "Běžící") tolik
>>> úloh,
>>> kolik má OS k dispozici logických CPU.
>>>  Uloha, která nemůže běžet, např. proto, že čeká na disk, je ve stavu
>>> "čekající" a nezabírá ŽÁDNÉ prostředky CPU. Rozhodně neplatí, že by
>>> "jádro
>>> čekalo", až disk dodá data. Je to uděláno tak, že na disk čeká 
>>> hardware -
>>> řadič disku - a jakmile disk dodá data, řadič je přijme, uloží do 
>>> bufferu
>>> (zcela automaticky pomocí DMA) a vygeneruje přerušení do CPU, to přeruší
>>> právě prováděnou úlohu, vyvolá obsluhu disku v jádru OS a pokud na data 
>>> z
>>> disku
>>> skutečně čekala nějaká úloha, jádro (modul plánovače - scheduleru) ji
>>> přesune
>>> z haldy úloh (heap - úlohy jsou tam bez nějakého řazení) čekajících do
>>> fronty
>>> úloh (řazené dle aktuální dynamické priority) připravených. Pokud to OS
>>> umí
>>> a priorita úlohy je dostatečně vysoká, provede se tzv. dynamický
>>> asynchronní
>>> rescheduling, kdy tato úloha dostane CPU a rozeběhne se, zatímco dříve
>>> běžící
>>> úloha je odstavena zpravidla na konec fronty úloh připravených.
>>>  Pokud je tedy co dělat - tzn. nejméně tolik připravených - běhu
>>> schopných
>>> -
>>> úloh, kolik je logických CPU, budou všechny dostupné logické CPU naplno
>>> zaměstnány během těchto úloh. Je-li běhu schopných úloh méně, jsou
>>> některé
>>> logické CPU "zaměstnány" tzv. klidovou úlohou - "idle task", která je
>>> zřízena
>>> v jádře OS proto, aby plánovač byl regulární - měl vždy po ruce úlohu i 
>>> v
>>> případě, že nic na systému nepožaduje běh. Tento idle task obvykle na HW
>>> úrovni vykoná instrukci HLT, což procesor uvede (ve spolupráci s ACPI
>>> subsystémem) do nějakého úsporného režimu spotřeby energie.
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list 