"uptime - sto je load average"
Valent Turkovic
cini mi se da je clanak malo fulao jer citajuci:
http://www.teamquest.com/resources/gunther/display/5/
pise explicitno:
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.
--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic
Valent Turkovic
> 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
Vedran Furač
> http://mzsl.wordpress.com/2008/09/24/uptime-sto-je-load-average/
>
> cini mi se da je clanak malo fulao jer citajuci:
> http://www.teamquest.com/resources/gunther/display/5/
> pise explicitno:
>
> 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).
Matija Papec
>> 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).
Nikola Ostrun
> 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.
>
> virtualna ma?iona, jo? jedno 5-6 traznih aplikacija, torrenti...) s 2GB
Pogledaj sa sar(1)-om na sto tocno se 'trosi' cpu.
Dinko Korunic
> Što je i jasno. Čovjek koji piše blog je mogao napraviti jednostavan
Jasno je bilo kome tko je ucio osnovne arhitekture operacijskih sustava,
ali ocito covjek to nije citao..
> 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
Nece biti minimalno optecen, osim ako si mislio samo na user-time?
> fajla s jedne ext3 particije na drugu LA je skočio na 10 (cfq io sched).
Kernel time se povecao, broj slotova za user-time se smanjio, broj
procesa/taskova u redu za cekanje se povecao.
--
NAME:Dinko.kreator.Korunic DISCLAIMER:Standard.disclaimer.applies
ICQ:16965294 JAB:kreat...@jabber.org PGP:0xEA160D0B
HOME:http://dkorunic.net QUOTE:Eat.right.stay.fit.and.die.anyway
Dinko Korunic
> Pogledaj sa sar(1)-om na sto tocno se 'trosi' cpu.
Definitivno bi vise saznao sa atop-om, sar je so 1980s :-)
Hrvoje Zeba
> /.../
khm... a sta nije load prosjecan broj aktivnih threadova u redu za
izvrsavanje?
--
I doubt, therefore I might be.
Igor Pozgaj
> 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 | ipozgaj at fly.srk.fer.hr
ICQ: 126002505 | IRC: @thunder (#linux@IdolNet)
PGP: 0xEF36A092 | http://fly.srk.fer.hr/~ipozgaj
http://ipozgaj.blogspot.com (/atom.xml RSS feed)
Hrvoje Zeba
> 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.
Jakov Sosic
> 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...
--
| Jakov Sosic | ICQ: 28410271 | PGP: 0x965CAE2D |
=================================================================
| start fighting cancer -> http://www.worldcommunitygrid.org/ |
Nikola Ostrun
> 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...
--
VI = Virtually Incomprehensible.
Nikola Ostrun
> On 2008-10-06, Igor Pozgaj <ipo...@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/ :-)
Vedran Furač
Ali ulazi u izračun LA na linuxu. Zato se i dobivaju ove "čudne" i
visoke brojke.
Hrvoje Zeba
>>>> 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 ;)
Vedran Furač
OK, ne znam ništa o AIX-u. Ovo "čudne i visoke brojke" se odnosilo na
onih mojih 10 kad kopiram fajl.
Vedran Furač
> On Mon, 06 Oct 2008 14:58:30 +0200, Vedran Furač wrote:
>> Što je i jasno. Čovjek koji piše blog je mogao napraviti jednostavan
>
> Jasno je bilo kome tko je ucio osnovne arhitekture operacijskih sustava,
> ali ocito covjek to nije citao..
>
>> 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
>
> Nece biti minimalno optecen, osim ako si mislio samo na user-time?
Ovisi o tome što je to "minimalno". U mom slučaju je to ~10%. To bi
trebalo bi ostaviti dosta prostora za ostale procese.
>> fajla s jedne ext3 particije na drugu LA je skočio na 10 (cfq io sched).
>
> Kernel time se povecao, broj slotova za user-time se smanjio, broj
> procesa/taskova u redu za cekanje se povecao.
Da.
Btw., proces cp je većinu vremena u "uninterruptible sleep" stanju (D u
ps-u). Možda i više nego što bi trebao pa to dodatno digne LA.
Hrvoje Kusulja
> http://mzsl.wordpress.com/2008/09/24/uptime-sto-je-load-average/
>
> cini mi se da je clanak malo fulao jer citajuci:
> http://www.teamquest.com/resources/gunther/display/5/
> pise explicitno:
>
> 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..
--
Hrvoje Kusulja
TSRB, CCNA, TVZ-Informatika
Dinko Korunic
> 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 :-)
Hrvoje Zeba
> 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 :-)
>
mudro :)
Nikola Ostrun
> 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;
for_each_online_cpu(i) {
running += cpu_rq(i)->nr_running;
uninterruptible += cpu_rq(i)->nr_uninterruptible;
}
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() :-)
Vedran Furač
> 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.
Hrvoje Zeba
a da te slucajno ne pati DMA?
Jakov Sosic
> Totalno. Trebas kupit jos jedan quadcore i prijeci na 128bitnu distru :-)
Ako ne OS onda barem FS ;)
Jakov Sosic
> Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili
> kak se već to zove na linuxu) onda nije /load/ :-)
Na Linuxu je... Za ostale OS-ove neznam...
Vedran Furač
A-a.
Hrvoje Zeba
disco
> Hrvoje Zeba wrote:
>> a da te slucajno ne pati DMA?
>
> A-a.
/bin/cp aka "no one else should use disk while i'm copying and i'll use
100% of cpu and fill all available ram thus invalidating cache so you'll
have to wait 15 seconds just to open a terminal even if you opened one
just couple of seconds before i started executing"?
--
Artificial intelligence is no match for natural stupidity.
Vedran Furač
errr?
Hrvoje Zeba
povezi taj post sa onim sto je Ostrun rekao...
Vedran Furač
> Vedran Furač wrote:
>> Hrvoje Zeba wrote:
>>> a da te slucajno ne pati DMA?
>> A-a.
>
> /bin/cp aka "no one else should use disk while i'm copying
Otprilike tako.
Vedran Furač
On je govorio samo o izračunu LA, ja o usporenju za vrijeme IO operacija.
Hrvoje Zeba
>>>>>> 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.
>>>>>
>>>> aaaa...
>>>>
>>>> http://uwsg.iu.edu/hypermail/linux/kernel/0205.1/0122.html
>>> errr?
>>>
>> povezi taj post sa onim sto je Ostrun rekao...
>
> On je govorio samo o izračunu LA, ja o usporenju za vrijeme IO operacija.
ok... a to sto load naraste dok kopiras nije vezano za
TASK_UNINTERRUPTIBLE flag i njegovo znacenje/upotrebu?
al nema veze... ak se hoces natezat, zakvaci gumu od bicikla za
radijator pa udri koliko te volja.
disco
> disco wrote:
>> /bin/cp aka "no one else should use disk while i'm copying
>
> Otprilike tako.
imam isti problem na linuxu. nije da branim windoze al' ranije dok sam
koristio vistu nisam skoro niti osjetio da se kopira file u pozadini.
Dinko Korunic
> imam isti problem na linuxu. nije da branim windoze al' ranije dok sam
> koristio vistu nisam skoro niti osjetio da se kopira file u pozadini.
Kratko: elevator=cfq te eventualno ionice.
Hrvoje Kusulja
daj ljepo pitam, nemojte me zezat...samo me zbunjujute...
dakle blog je tocan i server je preopterecen.., hvala..
disco
> Kratko: elevator=cfq te eventualno ionice.
cfq mi je vec default...
$ cat /sys/block/sd*/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
a ionice bi trebalo iz komandne linije no io koji me muci se dogadja u
gnomeu kad doubleclicknem na rar file pa mi otvori file roller i idem
extractat file od 8gb, a neda mi se svaki put otvarat terminal i rucno
ionice-at taj process.
Matija Nalis
> a ionice bi trebalo iz komandne linije no io koji me muci se dogadja u
> gnomeu kad doubleclicknem na rar file pa mi otvori file roller i idem
> extractat file od 8gb, a neda mi se svaki put otvarat terminal i rucno
> ionice-at taj process.
pa onda izmijeni mimetypes ili kaj vec koristi da ne otpakirava .rarove sa
'rar' nego sa 'ionice -c3 rar' ili kak vec hoces.
--
Opinions above are GNU-copylefted.
Vedran Furač
Bilo bi lijepo kad bih mogao postaviti defaultnu klasu za pojedini
program. Npr:
# cat /etc/io
/bin/cp c3
/usr/bin/kioslave c3
/usr/bin/tar c3
[...]
Vedran Furač
> Vedran Furač 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.
>>>>>>
>>>>> aaaa...
>>>>>
>>>>> http://uwsg.iu.edu/hypermail/linux/kernel/0205.1/0122.html
>>>> errr?
>>>>
>>> povezi taj post sa onim sto je Ostrun rekao...
>> On je govorio samo o izračunu LA, ja o usporenju za vrijeme IO operacija.
>
> ok... a to sto load naraste dok kopiras nije vezano za
> TASK_UNINTERRUPTIBLE flag i njegovo znacenje/upotrebu?
Jedini primjetni efekt koji proces u takvom stanju ima jest taj da ga ne
možeš ubit. Ne mora doći do usporenja.
Matija Nalis
> Matija Nalis wrote:
>> pa onda izmijeni mimetypes ili kaj vec koristi da ne otpakirava .rarove sa
>> 'rar' nego sa 'ionice -c3 rar' ili kak vec hoces.
>
> Bilo bi lijepo kad bih mogao postaviti defaultnu klasu za pojedini
> program. Npr:
>
> # cat /etc/io
> /bin/cp c3
> /usr/bin/kioslave c3
> /usr/bin/tar c3
> [...]
nesto tipa (odokativno) :
#!/bin/sh
while read cmd prio
do
dpkg-divert --rename $cmd
cat <<EOF > $cmd
#!/bin/sh
exec ionice -$prio $cmd.distrib "\$@"
EOF
chmod 755 $cmd
done < /etc/io
ok, treba ga mozda malo optimizat da skipa one koje je vec napravio (ili
dpkg-divert po defaultu tu bailouta? trebalo bi RTFMat i/ili probati), i
pametnije permissione (i tcc mozda umjesto shell scripte radi SUID/SGID) no
to bi generalno trebalo prozvakati tvoj /etc/io i napraviti "the right
thing" :)
mislim da je veci problem sto promjena IO klase, cak i u nizi IDLE -c3,
*by design* zahtjeva roota (a dizajn je takav jer se inace prekrasno mogu
iskoristiti da IRL skoro nemoguce timing race napade, lokalne DoSove itd).
Mozes mrdati "-n"ove u klasi, though.
Aleksandar Ivanisevic
> al nema veze... ak se hoces natezat, zakvaci gumu od bicikla za
> radijator pa udri koliko te volja.
Haha, odlicna, vrlo sam u napasti da promijenim .sig ;)
--
To sto si frustriran, zavidan tko zna na cemu i sto ne vidis dalje od
svoje guzice je tuzno. Da onda barem imas toliko samokontrole da
sutis umjesto da pravis budalu od sebe... izgleda da si prestar da se
promjenis na bolje. - Davor Pasaric, hr.comp.mac
Hrvoje Zeba
> Hrvoje Zeba <hrvoje.z...@MEmail.chihq.org> writes:
>
>> al nema veze... ak se hoces natezat, zakvaci gumu od bicikla za
>> radijator pa udri koliko te volja.
>
> Haha, odlicna, vrlo sam u napasti da promijenim .sig ;)
>
:)
Hrvoje Kusulja
> load average: 4.17, 4.75, 4.81
hmm da, to sam si i mislio, ubio sam jednu od par vmware masina... i onda
je sad normalno na 1.0 - 2.0.
ta masina je ima windows 2003, i dvije java aplikacije (jedna za monitoring
SNMP, i druga za Helpdesk), to odpocetka radi uzasno sporo.. a i svaka
aplikacija je "velika" i ima svoj mali mysql server i bla, bla...
posto na tom serveru imam jos drugih windows 2003 masina, i svega, radi bez
greska, ova prva s javom je kriva..
i sad je ok..
inace sam vec 3x plocice RAMA mjenjao.. te 2x hard diska...
glupa java... :)
trazim alternativu :P, no otom potom
Nikola Ostrun
> On Mon, 6 Oct 2008 22:48:24 +0200, Hrvoje Kusulja wrote:
>
>> load average: 4.17, 4.75, 4.81
>
> ponekad je preslo 5.0 !!!!
>
> hmm da, to sam si i mislio, ubio sam jednu od par vmware masina... i onda
> je sad normalno na 1.0 - 2.0.
Zašto bi load 1.0 - 2.0 bio normalan? Koliko ti jezgri ima proc?
> ...
> glupa java... :)
>
> trazim alternativu :P, no otom potom
Sretno...
Nikola Ostrun
> On 2008-10-06, Nikola Ostrun <nikola...@email.t-com.hr> wrote:
>
>> Ako proces/dretva *čeka* nešto (ako joj stanje nije RUNNABLE ili
>> kak se već to zove na linuxu) onda nije /load/ :-)
>
> Na Linuxu je... Za ostale OS-ove neznam...
Eh, nisu sve dretve koje čekaju load. Nešto takvo jednostavno nebi
imalo smisla. Inače, brijem da sad znam što je tako posebno sa
TASK_UNINTERRUPTIBLE dretvama:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0008.3/0924.html
Ko bi reko, čak zvuči logično...
Hrvoje Kusulja
> Hrvoje Kusulja <hkusulj...@kusulja.com> writes:
>
>> On Mon, 6 Oct 2008 22:48:24 +0200, Hrvoje Kusulja wrote:
>>
>>> load average: 4.17, 4.75, 4.81
>>
>> ponekad je preslo 5.0 !!!!
>>
>> hmm da, to sam si i mislio, ubio sam jednu od par vmware masina... i onda
>> je sad normalno na 1.0 - 2.0.
>
> Zašto bi load 1.0 - 2.0 bio normalan? Koliko ti jezgri ima proc?
>
rekao u par postova prije quad core je..
Vedran Furač
> nesto tipa (odokativno) :
>
> #!/bin/sh
> while read cmd prio
> do
> dpkg-divert --rename $cmd
> cat <<EOF > $cmd
> #!/bin/sh
> exec ionice -$prio $cmd.distrib "\$@"
> EOF
> chmod 755 $cmd
> done < /etc/io
Uh koji hack. :-)
> ok, treba ga mozda malo optimizat da skipa one koje je vec napravio (ili
> dpkg-divert po defaultu tu bailouta? trebalo bi RTFMat i/ili probati), i
> pametnije permissione (i tcc mozda umjesto shell scripte radi SUID/SGID) no
> to bi generalno trebalo prozvakati tvoj /etc/io i napraviti "the right
> thing" :)
>
> mislim da je veci problem sto promjena IO klase, cak i u nizi IDLE -c3,
> *by design* zahtjeva roota (a dizajn je takav jer se inace prekrasno mogu
> iskoristiti da IRL skoro nemoguce timing race napade, lokalne DoSove itd).
> Mozes mrdati "-n"ove u klasi, though.
IMO, kernel bi trebao imati algoritme koji bi procijenili da li je user
startao proces kojemu je jedina funkcije kopiranje (npr. cp(1) - da,
gimp - ne) i koji kopira vece kolicine podataka pa mu automatski
dodijeliti IDLE IO klasu.
Jakov Sosic
> rekao u par postova prije quad core je..
E pa sta je jednojezgrenom stroju 1-2, njemu je 4-8 :)
Hrvoje Kusulja
> On 2008-10-09, Hrvoje Kusulja <hkusulj...@kusulja.com> wrote:
>
>> rekao u par postova prije quad core je..
>
> E pa sta je jednojezgrenom stroju 1-2, njemu je 4-8 :)
pa da, u svakom slucaju dakle nesmije proci 1.0 jelda ?, tj. kod mene 4.0 ?
Nikola Ostrun
> On Thu, 09 Oct 2008 20:13:11 +0200, Nikola Ostrun wrote:
>
>> Hrvoje Kusulja <hkusulj...@kusulja.com> writes:
>>
>>> On Mon, 6 Oct 2008 22:48:24 +0200, Hrvoje Kusulja wrote:
>>>
>>>> load average: 4.17, 4.75, 4.81
>>>
>>> ponekad je preslo 5.0 !!!!
>>>
>>> hmm da, to sam si i mislio, ubio sam jednu od par vmware masina... i onda
>>> je sad normalno na 1.0 - 2.0.
>>
>> Zašto bi load 1.0 - 2.0 bio normalan? Koliko ti jezgri ima proc?
>>
> rekao u par postova prije quad core je..
Znam, mislio sam da će te pitanje natjerat da razmisliš. No OK. Ako
imaš četiri jezgre, kak prosječno 1.0 - 2.0 dretvi u *svim* redovima
dretvi na *svim* jezgrama može biti normalno (normalno u smislu da ti
proc većinu vremena ne prodaje zjake)?
Matija Nalis
> Matija Nalis wrote:
>> nesto tipa (odokativno) :
>> exec ionice -$prio $cmd.distrib "\$@"
>> EOF
>> chmod 755 $cmd
>> done < /etc/io
>
> Uh koji hack. :-)
Za dodatni bonus, stavis ga u cron svakih 5 minuta (ili, more advanced
verzija, napises jednostavni mikro dnotify handler) i imas i da se dogadja
"automatski" cim promjenis /etc/io :)
>> mislim da je veci problem sto promjena IO klase, cak i u nizi IDLE -c3,
>> *by design* zahtjeva roota (a dizajn je takav jer se inace prekrasno mogu
>> iskoristiti da IRL skoro nemoguce timing race napade, lokalne DoSove itd).
>> Mozes mrdati "-n"ove u klasi, though.
>
> IMO, kernel bi trebao imati algoritme koji bi procijenili da li je user
> startao proces kojemu je jedina funkcije kopiranje (npr. cp(1) - da,
> gimp - ne) i koji kopira vece kolicine podataka pa mu automatski
> dodijeliti IDLE IO klasu.
A kako ces to razlikovati ?
gimp(1) kada npr. snima malo veci tiff je jednaki (ili jos gori) I/O hog kao
i cp(1). I definitivno zelim da se ponasa isto u danom trenu, a ne da mi
pojede sav ram i zaustavi sve ostalo na masini. Ripanje ili obdrada filmica
i sl da ne spominjemo.
Osim toga, ideja (s kojom se ja osobno slazem[0]) je "keep policy out of the
kernel!". U kernelu drzi infrastrukturu, ali sam policy drzi u userspacu.
Tako imas ioprio_set(2). Imas i madvise(2). [1][C Pa neka ga programi tipa
cp(1) i gimp(1) i ostali koriste (hey, imas source, i bez znanja programiranja
svatko moze dodati jedan red na pocetak main())
Da ne spominjemo da doticna metodologija drzanja policya u userspaceu
zapravo omogucava svakome da podesi onako kako ON hoce za svaki proces
posebno, a ne da se SVE uvijek mora ponasati onako kako neki tamo kernel
scheduler je zakljucio.
[0] Razloge zasto smo nadam se davno proslo sa devfs/udev, OOM killerom itd.
[1] ako imas neke zamjerke oko funkcionalnosti doticnih syscallova, to je OK.
Dapace, patches welcome :)
Ali "kernel bi trebao imati policy koji ce meni citati misli" nije OK.
Citanje misli naime spada u domenu sistem integratora :) (gdje ce za
razne stvari razne distre gurati defaulte svaka na svoju stranu) a ne u
domenu kernel developera.
Jakov Sosic
> pa da, u svakom slucaju dakle nesmije proci 1.0 jelda ?, tj. kod mene 4.0 ?
Nema tu pravila. Moze bit 20 a da je sve ok, a moze bit 2 i da ti stroj
umire, ako je to 2 cekanje na I/O...
Ako stroj radi dovoljno brzo, ne zamaraj se...
Vedran Furač
> On 2008-10-09, Vedran Furač <ved...@vedranf.mine.nu> wrote:
>> Matija Nalis wrote:
>>> nesto tipa (odokativno) :
>>> [...]
>>> exec ionice -$prio $cmd.distrib "\$@"
>>> EOF
>>> chmod 755 $cmd
>>> done < /etc/io
>> Uh koji hack. :-)
>
> Za dodatni bonus, stavis ga u cron svakih 5 minuta (ili, more advanced
> verzija, napises jednostavni mikro dnotify handler) i imas i da se dogadja
> "automatski" cim promjenis /etc/io :)
>
>>> mislim da je veci problem sto promjena IO klase, cak i u nizi IDLE -c3,
>>> *by design* zahtjeva roota (a dizajn je takav jer se inace prekrasno mogu
>>> iskoristiti da IRL skoro nemoguce timing race napade, lokalne DoSove itd).
>>> Mozes mrdati "-n"ove u klasi, though.
>> IMO, kernel bi trebao imati algoritme koji bi procijenili da li je user
>> startao proces kojemu je jedina funkcije kopiranje (npr. cp(1) - da,
>> gimp - ne) i koji kopira vece kolicine podataka pa mu automatski
>> dodijeliti IDLE IO klasu.
>
> A kako ces to razlikovati ?
Teško, znam. Uglavnom, windowsi to rade bolje nego linux.
> gimp(1) kada npr. snima malo veci tiff je jednaki (ili jos gori) I/O hog kao
> i cp(1). I definitivno zelim da se ponasa isto u danom trenu, a ne da mi
> pojede sav ram i zaustavi sve ostalo na masini.
Da, ali spremanje jednog tiff-a traje relativno kratko. OK, postoje
iznimke kad slika ima 100MB, ali to nije toliko često.
> Ripanje ili obdrada filmica i sl da ne spominjemo.
Ako je I/O za određeni proces dug i monoton, onda bi mu automatski
trebalo smanjiti I/O prioritet.
> Osim toga, ideja (s kojom se ja osobno slazem[0]) je "keep policy out of the
> kernel!". U kernelu drzi infrastrukturu, ali sam policy drzi u userspacu.
I/O scheduleri se nalaze u kernelu, zar ne?
Matija Nalis
> Matija Nalis wrote:
>> On 2008-10-09, Vedran Furač <ved...@vedranf.mine.nu> wrote:
>>> startao proces kojemu je jedina funkcije kopiranje (npr. cp(1) - da,
>>> gimp - ne) i koji kopira vece kolicine podataka pa mu automatski
>>> dodijeliti IDLE IO klasu.
>>
>> A kako ces to razlikovati ?
>
> Teško, znam. Uglavnom, windowsi to rade bolje nego linux.
Ne bih znao. Jesi siguran da je problem u linuxu (kernelu), a ne u alatima
koje koristis (stojaznam, KDE ili whatever za kopiranje) ? Takodjer, znam
nesto ljudi koji uzasno jadikuju kako lose windoze (xp) handleaju I/O,
tako da je moguce da je to samo tebi. Ja ih ne trosim, pa ne bih znao...
>> gimp(1) kada npr. snima malo veci tiff je jednaki (ili jos gori) I/O hog kao
>> i cp(1). I definitivno zelim da se ponasa isto u danom trenu, a ne da mi
>> pojede sav ram i zaustavi sve ostalo na masini.
>
> Da, ali spremanje jednog tiff-a traje relativno kratko. OK, postoje
> iznimke kad slika ima 100MB, ali to nije toliko često.
Mozda tebi, ako obradjuje slikice iz low-entry consumed digitalnih
fotoaparata od pred par godina. Bilo kome tko se bavi slikicama je to
beskonacno veci problem.
>> Ripanje ili obdrada filmica i sl da ne spominjemo.
>
> Ako je I/O za određeni proces dug i monoton, onda bi mu automatski
> trebalo smanjiti I/O prioritet.
To je relativno jednostavno za izvesti. No zanemarujes cinjenicu da nemas
dva procesa u igri od kojih je jedan interaktivan a drugi nije, nego da ih
imas hrpetinu, i da se oni svi tuku za isti resurs. IRL, sa necim ovakvim,
svi procesi koji nesto zapravo rade sa diskom bi bili konstantno zakucani
dolje i vjerovatno bi starveali (ako bi radio na sistemu IOPRIO_CLASS_IDLE)
i/ili bi znacajno porusili ukupne performanse sistema na non-SSD storageu
(jer bi time sabotirao elevator mehanizam).
Ne znam sto tebe tocno muci, meni stvari rade ok. Ako zelis dodijeliti bolji
I/O, stojaznam, gimpu, onda mu jednostavno digni prioritet u best effort CFQ
klasi recimo sa ionice(1). Ili, alternativno, samo spusti prioritet onome za
sto ti performanse nisu bitne (neka kopiranja velikih fileova ili stogod).
>> Osim toga, ideja (s kojom se ja osobno slazem[0]) je "keep policy out of the
>> kernel!". U kernelu drzi infrastrukturu, ali sam policy drzi u userspacu.
>
> I/O scheduleri se nalaze u kernelu, zar ne?
Da. To je tocno to sto sam rekao. Dakle userspace odredjuje policy koji
scheduler ce koristiti za koji block device, te koji ce biti njegovi
parametri i hintovi (ioprio_set, madvise itd.).