You would be forgiven for jumping to the conclusion that the "load" is the same thing as the CPU utilization. As the Linux results show, when two hot processes are running, the maximum load is two (not one) on a single CPU. So, load is not equivalent to CPU utilization.
On Mon, 06 Oct 2008 12:36:37 +0000, Valent Turkovic wrote: > cini mi se da je clanak malo fulao jer citajuci:
Eh, ja sam prebrzo iscitao i krivo zakljucio :)
Ono sto me zbunjuje je to da imam veliki load average na stroju koji je vrlo malo opterecen (4 aktivna torrenta), opterecenje procesora je 20-30% ali load je vrlo velik - 3.59 4.12 3.90
Procesor je AMD Barton 2500+ (radi na 2000Mhz) i sistem ima 512MB memorije.
Dok na drugom stroju koji je jako opterečen (firefox s 20-30 tabova, virtualna mašiona, još jedno 5-6 traznih aplikacija, torrenti...) s 2GB rama i kojem je CPU stalno na 90-100% load je - 2.12, 2.53, 2.75
> You would be forgiven for jumping to the conclusion that the "load" is > the same thing as the CPU utilization. As the Linux results show, when > two hot processes are running, the maximum load is two (not one) on a > single CPU. So, load is not equivalent to CPU utilization.
Što je i jasno. Čovjek koji piše blog je mogao napraviti jednostavan test: kopirati fajl s jedne particije na drugu. Procesor će biti minimalno opterećen, a LA će skočiti. Kod mene, na kraju kopiranja 3GB fajla s jedne ext3 particije na drugu LA je skočio na 10 (cfq io sched).
Valent Turkovic wrote: >> cini mi se da je clanak malo fulao jer citajuci:
> Eh, ja sam prebrzo iscitao i krivo zakljucio :)
> Ono sto me zbunjuje je to da imam veliki load average na stroju koji je > vrlo malo opterecen (4 aktivna torrenta), opterecenje procesora je 20-30% > ali load je vrlo velik - 3.59 4.12 3.90
> Procesor je AMD Barton 2500+ (radi na 2000Mhz) i sistem ima 512MB > memorije.
To je i mene cudilo na jednoj masini, ali se ispostavilo da na momente disk nesto intezivno vrti dok cpu idla (ili odlazi u wait).
> On Mon, 06 Oct 2008 12:36:37 +0000, Valent Turkovic wrote:
>> cini mi se da je clanak malo fulao jer citajuci:
> Eh, ja sam prebrzo iscitao i krivo zakljucio :)
> Ono sto me zbunjuje je to da imam veliki load average na stroju koji je > vrlo malo opterecen (4 aktivna torrenta), opterecenje procesora je 20-30% > ali load je vrlo velik - 3.59 4.12 3.90
> Procesor je AMD Barton 2500+ (radi na 2000Mhz) i sistem ima 512MB > memorije.
> Dok na drugom stroju koji je jako optere?en (firefox s 20-30 tabova, > virtualna ma?iona, jo? jedno 5-6 traznih aplikacija, torrenti...) s 2GB > rama i kojem je CPU stalno na 90-100% load je - 2.12, 2.53, 2.75
Pogledaj sa sar(1)-om na sto tocno se 'trosi' cpu.
On Mon, 06 Oct 2008 18:00:29 +0200, Hrvoje Zeba wrote: > Dinko Korunic wrote: >> /.../
> khm... a sta nije load prosjecan broj aktivnih threadova u redu za > izvrsavanje?
Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB memorije, FC diskovi) imao load average oko 270, a radio je cisto ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija broja mijenja s vecim brojem kora/procesora.
Igor Pozgaj wrote: > On Mon, 06 Oct 2008 18:00:29 +0200, Hrvoje Zeba wrote:
>> Dinko Korunic wrote: >>> /.../ >> khm... a sta nije load prosjecan broj aktivnih threadova u redu za >> izvrsavanje?
> Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam > nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB > memorije, FC diskovi) imao load average oko 270, a radio je cisto > ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi > sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija > broja mijenja s vecim brojem kora/procesora.
to ti je cca 11 threadova po procesoru sto ne bi trebalo biti strasno (a i ovisi o vrsti threadova koji se vrte) a trebao bi i pogledati sto se sve na AIX-u smatra aktivnim threadom.
On 2008-10-06, Igor Pozgaj <ipoz...@nospam.fly.srk.fer.hr> wrote:
> Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam > nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB > memorije, FC diskovi) imao load average oko 270, a radio je cisto > ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi > sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija > broja mijenja s vecim brojem kora/procesora.
Pa naravno da stroj radi ok - kad je moguce da 260 od tih 270 ceka na "izlazak sunca" i time samo stoji u queue i uopce ne opterecuju stroj... Load zna strasno zavarati...
Dinko Korunic <dinko.koru...@gmail.com> writes: > On Mon, 6 Oct 2008 13:27:57 +0000 (UTC), Nikola Ostrun wrote: >> Pogledaj sa sar(1)-om na sto tocno se 'trosi' cpu.
> Definitivno bi vise saznao sa atop-om, sar je so 1980s :-)
Zašto? Da vidi postotke CPU usagea po kategorijama mu je sar(1) savršen. Doduše, nisam mislio da je pregled po procesu bitan...
Jakov Sosic <jso...@jsosic.homeunix.org> writes: > On 2008-10-06, Igor Pozgaj <ipoz...@nospam.fly.srk.fer.hr> wrote:
>> Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam >> nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB >> memorije, FC diskovi) imao load average oko 270, a radio je cisto >> ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi >> sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija >> broja mijenja s vecim brojem kora/procesora.
> Pa naravno da stroj radi ok - kad je moguce da 260 od tih 270 ceka > na "izlazak sunca" i time samo stoji u queue i uopce ne opterecuju > stroj... Load zna strasno zavarati...
Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili kak se već to zove na linuxu) onda nije /load/ :-)
Nikola Ostrun wrote: > Jakov Sosic <jso...@jsosic.homeunix.org> writes:
>> On 2008-10-06, Igor Pozgaj <ipoz...@nospam.fly.srk.fer.hr> wrote:
>>> Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam >>> nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB >>> memorije, FC diskovi) imao load average oko 270, a radio je cisto >>> ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi >>> sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija >>> broja mijenja s vecim brojem kora/procesora. >> Pa naravno da stroj radi ok - kad je moguce da 260 od tih 270 ceka >> na "izlazak sunca" i time samo stoji u queue i uopce ne opterecuju >> stroj... Load zna strasno zavarati...
> Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili > kak se već to zove na linuxu) onda nije /load/ :-)
Ali ulazi u izračun LA na linuxu. Zato se i dobivaju ove "čudne" i visoke brojke.
Vedran Furač wrote: >>>> Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam >>>> nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB >>>> memorije, FC diskovi) imao load average oko 270, a radio je cisto >>>> ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi >>>> sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija >>>> broja mijenja s vecim brojem kora/procesora. >>> Pa naravno da stroj radi ok - kad je moguce da 260 od tih 270 ceka >>> na "izlazak sunca" i time samo stoji u queue i uopce ne opterecuju >>> stroj... Load zna strasno zavarati... >> Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili >> kak se već to zove na linuxu) onda nije /load/ :-)
> Ali ulazi u izračun LA na linuxu. Zato se i dobivaju ove "čudne" i > visoke brojke.
Hrvoje Zeba wrote: > Vedran Furač wrote: >>>>> Je, ali taj broj ti nece puno toga reci sam po sebi. Recimo ja sam >>>>> nedavno na poslu imao situaciju da je stroj (AIX, 24 corea, 128 GB >>>>> memorije, FC diskovi) imao load average oko 270, a radio je cisto >>>>> ok. Stvari koje ljudi zaboravljaju su da je to *average* (usporedi >>>>> sa prvom kolonom u ispisu naredbe vmstat 60) te da se interpretacija >>>>> broja mijenja s vecim brojem kora/procesora. >>>> Pa naravno da stroj radi ok - kad je moguce da 260 od tih 270 ceka >>>> na "izlazak sunca" i time samo stoji u queue i uopce ne opterecuju >>>> stroj... Load zna strasno zavarati... >>> Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili >>> kak se već to zove na linuxu) onda nije /load/ :-) >> Ali ulazi u izračun LA na linuxu. Zato se i dobivaju ove "čudne" i >> visoke brojke.
> pozgaj je govorio za aix ;)
OK, ne znam ništa o AIX-u. Ovo "čudne i visoke brojke" se odnosilo na onih mojih 10 kad kopiram fajl.
> You would be forgiven for jumping to the conclusion that the "load" is > the same thing as the CPU utilization. As the Linux results show, when > two hot processes are running, the maximum load is two (not one) on a > single CPU. So, load is not equivalent to CPU utilization.
> Valent.
ok mene je sada zbunio taj blog s vasim komentarima...
imam dakle quad core, 8gb ram, 64bit ubuntu-server..
load average: 4.17, 4.75, 4.81
dal to znaci da je u prosjeku u 1min, 5 min i 15 min, moj server preopterecen ?
ili sam nesto krivo shvatio.. tj. drugim rjecima, dal je blog tocan ili nije tocan ? (ako nije, sta je onda tocno objasnjenje tih triju brojki) hvala..
On Mon, 6 Oct 2008 22:48:24 +0200, Hrvoje Kusulja wrote: > imam dakle quad core, 8gb ram, 64bit ubuntu-server.. > load average: 4.17, 4.75, 4.81 > dal to znaci da je u prosjeku u 1min, 5 min i 15 min, moj server > preopterecen ?
Totalno. Trebas kupit jos jedan quadcore i prijeci na 128bitnu distru :-)
Dinko Korunic wrote: > On Mon, 6 Oct 2008 22:48:24 +0200, Hrvoje Kusulja wrote: >> imam dakle quad core, 8gb ram, 64bit ubuntu-server.. >> load average: 4.17, 4.75, 4.81 >> dal to znaci da je u prosjeku u 1min, 5 min i 15 min, moj server >> preopterecen ?
> Totalno. Trebas kupit jos jedan quadcore i prijeci na 128bitnu distru :-)
Vedran Furač <vedr...@vedranf.mine.nu> writes: > Nikola Ostrun wrote: ... >> Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili >> kak se već to zove na linuxu) onda nije /load/ :-)
> Ali ulazi u izračun LA na linuxu. Zato se i dobivaju ove "čudne" i > visoke brojke.
HAH, na linuxu se stvarno uzimaju. Ne sve koje čekaju, nego samo one sa stanjem TASK_UNINTERRUPTIBLE. Gledam u kern/timer.c funkciju calc_load() koja na kraju poziva nr_active() iz kern/sched.c da sazna broj "aktivnih" dretvi:
unsigned long nr_active(void) { unsigned long i, running = 0, uninterruptible = 0;
if (unlikely((long)uninterruptible < 0)) uninterruptible = 0;
return running + uninterruptible;
}
i sad me zanima što je tako posebno sa TASK_UNINTERRUPTIBLE dretvama da ih se smatra aktivnima...
Inače, u kern/sched.c postoji nr_running() koja je slična nr_active() samo što ne broji TASK_UNINTERRUPTIBLE dretve. Ak te muči visok load zamijeni u kern/timer.c u funkciji count_active_tasks() nr_active() sa nr_running() :-)
Nikola Ostrun wrote: > Inače, u kern/sched.c postoji nr_running() koja je slična > nr_active() samo što ne broji TASK_UNINTERRUPTIBLE dretve. Ak te muči > visok load zamijeni u kern/timer.c u funkciji count_active_tasks() > nr_active() sa nr_running() :-)
:-)
Ne mući me to, već to što svako kopiranje veće količine podataka značajno uspori sve ostale operacije.
>> Inače, u kern/sched.c postoji nr_running() koja je slična >> nr_active() samo što ne broji TASK_UNINTERRUPTIBLE dretve. Ak te muči >> visok load zamijeni u kern/timer.c u funkciji count_active_tasks() >> nr_active() sa nr_running() :-)
> :-)
> Ne mući me to, već to što svako kopiranje veće količine podataka > značajno uspori sve ostale operacije.
|
