(long) Re: pomalost LINUXU
David Jez
dave.jez na seznam.cz
Pátek Únor 23 09:22:37 CET 2001
On Thu, Feb 22, 2001 at 03:18:20PM -0500, Daniel Smolik wrote:
> Petr Kubicek wrote:
> >
> > > On Thu, Feb 22, 2001 at 12:36:59AM +0100, Michal Vadila wrote:
> > > > Nie je pravda. Program mpg123 seka aj na 700MHz AMD (100% vyskusane).
> > > > Staci pritom kopirovat nejaky naozaj vacsi subor a pri tom sa spusti
> > > > trebars updatedb a je to v keli. Nepomoze ani 128 MB RAM, ani rychlost
> > > > procesora ani buffer akejkolvek velkosti. Kto neverite, skuste si to!
> > > >
> > > Tak tohle je IMHO blbost, sam provozuji mpg123 jak s eq tak bez na AMD
> > > k6-III 128 MB RAM a jeste se mi _nikdy_ nesekl pri vetsi ani hodne velke
> > > zatezi. Jen jsem ho nezkousel pri pristupu na ZIPku kdy se seka i mys v Xkach.
> > >
> > > To ze mam rychly UDMA/66 Maxtor disk podle me nehraje zadnou vetsi roly.
> > > Tzn. podivej se kde mas co blbe, to se nemuze na 700ce sekat :-)
> > >
> >
> > Rekl bych, ze nema. Pri intezivni I/O na disku (o cemz pise) se muze kousat i vstup
> > z klavesnice. Zkuste si poustit dd if=/dev/zero of=/home/testfile bs=1024
> > count=500000. Prehrava porad plynule? Pokud ano muzete to pridat jeste jednou
> > s jinym "of". Ovsem ze by zrovna tohle resili MS Win lepe to nevim.
> > Vyzkouseno s lowlatency patches, ale porad to neni ono. Kdyz se nejaka aplikace
> > intenzivne chytne disku, je to poznat vic nez by bylo zdravo. Jadro ma
> > IDE radic inteligentni zatizeni CPU byva max. 15%. Jde tomu nejak pomoct?
> Jasne vyhod ide zakup SCSI :-). Jednou jsem slysel, ze
> hlavni problem rodiny x86 je doba navratu z obsluhy
> preruseni. A kdyz se podivas kolik ti ve srovnani z SCSI
> radicem hodi IDE preruseni ....
>
Dobre,
pustim si mpg123 s mp3 komprimovanym promena delka toku, velice kvalitni a take
velice narocny na pocitani
Abych vytizil procal spustim 10x obligatni ,,sploit":
for(;;) malloc(1);
Jadro provede OOM a je to v pohode.
Vetsi zatez na disku: Kopiruji soubory ext2->ext2 a spustim neco na zatez
flash:/tmp/aaa> dd if=/dev/urandom of=pokus bs=1000000 count=100 &
[1] 382
flash:/tmp/aaa> dd if=/dev/urandom of=pokus1 bs=1000000 count=100 &
[2] 383
flash:/tmp/aaa> dd if=/dev/urandom of=pokus2 bs=1000000 count=100 &
[3] 384
flash:/tmp/aaa> dd if=/dev/urandom of=pokus3 bs=1000000 count=100 &
[4] 385
8:57pm up 1:15, 4 users, load average: 4.27, 2.32, 0.95
70 processes: 64 sleeping, 6 running, 0 zombie, 0 stopped
CPU states: 6.8% user, 93.1% system, 0.0% nice, 0.0% idle
Mem: 119252K av, 117564K used, 1688K free, 0K shrd, 960K buff
Swap: 0K av, 0K used, 0K free 76312K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM CTIME COMMAND
382 dave 17 0 1416 1416 368 R 0 23.5 1.1 0:49 dd
383 dave 15 0 1416 1416 368 R 0 22.5 1.1 0:45 dd
384 dave 15 0 1416 1416 368 R 0 22.5 1.1 0:44 dd
385 dave 16 0 1416 1416 368 R 0 22.5 1.1 0:43 dd
390 dave 10 0 6516 6516 6108 S 0 4.9 5.4 0:09 mpg123
387 dave 11 0 1252 1252 1048 R 0 1.9 1.0 0:03 top
259 root 9 0 24104 23M 900 S 0 0.9 20.2 0:17 X
386 root 9 0 1872 1872 1460 R 0 0.9 1.5 0:00 xterm
1 root 8 0 60 60 32 S 0 0.0 0.0 0:12 init
2 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 keventd
3 root 9 0 0 0 0 SW 0 0.0 0.0 62:14 kapm-idled
4 root 9 0 0 0 0 SW 0 0.0 0.0 0:01 kswapd
5 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 kreclaimd
6 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 bdflush
7 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate
19 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 khubd
116 bin 9 0 76 76 0 S 0 0.0 0.0 0:00 rpc.portmap
pri zurivem prepinani mezi X -> console mi to teda jednou lupne, no.
OK, zmenim mpg123 za xmms. To me nelupe uz vubec. Takze to zase uplne spatne
neni. Widle lupaji asi vterinu nebo dve pri prechodu grafika -> text a naopak
(!) Takze porad jsem na tom se zlomek vterinovym lupnutim lepe. A bez nejakeho
extra dalsiho bufferu. BTW pochopitelne neswapuji, mozna to je zcasti i tim.
Za dalsi. Zaseky pod widlama se daji odstranit jedine zvysenim priority. Super
takze funguje to tak, ze widle winampu daji ring mode 0 ! tak to je absolutni
blbost, protoze se me zrovna vcera takhle hryzly a uz nenabehl ani task-list. To
je podle tebe ten spravny pristup k disku? To je vylozene vysmech ve srovnani s
nice (i kdyz linux nema buhvijak dobry scheduler)
9:02pm up 1:19, 4 users, load average: 4.04, 3.50, 1.82
70 processes: 61 sleeping, 9 running, 0 zombie, 0 stopped
CPU states: 1.9% user, 98.0% system, 0.0% nice, 0.0% idle
Mem: 119252K av, 117568K used, 1684K free, 0K shrd, 1128K buff
Swap: 0K av, 0K used, 0K free 74556K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM CTIME COMMAND
382 dave 16 0 1416 1416 368 R 0 23.6 1.1 1:53 dd
384 dave 16 0 1416 1416 368 R 0 23.6 1.1 1:47 dd
385 dave 16 0 1416 1416 368 R 0 23.6 1.1 1:47 dd
383 dave 15 0 1416 1416 368 R 0 22.6 1.1 1:49 dd
387 dave 11 0 1252 1252 1048 R 0 3.7 1.0 0:11 top
259 root 9 0 25056 24M 1240 S 0 1.8 21.0 0:29 X
409 dave 9 0 6904 6904 4144 R 0 0.9 5.7 0:01 xmms
1 root 8 0 60 60 32 S 0 0.0 0.0 0:12 init
2 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 keventd
3 root 9 0 0 0 0 SW 0 0.0 0.0 62:14 kapm-idled
4 root 9 0 0 0 0 SW 0 0.0 0.0 0:01 kswapd
5 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 kreclaimd
6 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 bdflush
7 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate
19 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 khubd
116 bin 9 0 76 76 0 S 0 0.0 0.0 0:00 rpc.portmap
119 root 9 0 224 224 116 S 0 0.0 0.1 0:00 syslogd
zahrati:
SYS Temp: +46.9°C (limit = +50°C, hysteresis = -8°C)
CPU Temp: +38.8°C (limit = +50°C, hysteresis = +60°C)
SBr Temp: +24.8°C (limit = +50°C, hysteresis = +60°C)
Pote teplota opet klesne na 30 °C.
PS: Uz me tenhle thread unavuje a myslim si ze nejsem sam. Takze pripadne reakce
privatne, do konference na tema widle-linux nehodlam psat a tyto thready
ignoruji
--
-------------------------------------------------------
David "Dave" Jez Brno, CZ, Europe
E-mail: dave.jez na seznam.cz
PGP key: finger xjezda00 na fest.stud.fee.vutbr.cz
---------=[ ~EOF ]=------------------------------------
Další informace o konferenci Linux