Messages in this thread | | | Date | Fri, 8 Nov 2002 16:08:30 -0500 (EST) | Subject | Re: [BENCHMARK] 2.5.46-mm1 with contest | From | "Alan Willis" <> |
| |
Ok, it just happened again. Everything got slow, changing desktops, starting new aterms,. etc. I flipped to a tty, and started a vmstat log, and went back into X, and reprioritised stuff with a terminal that was just bearably slow enough to work. After renicing X stuff got a bit better. A little. After renicing my aterms, it got slightly better still.
alan@aries:~$ sudo renice -19 `pgrep X` 499: old priority 0, new priority -19 alan@aries:~$ sudo renice -19 `pgrep aterm` 686: old priority 0, new priority -19 818: old priority 0, new priority -19 1030: old priority 0, new priority -19 1130: old priority 0, new priority -19 1202: old priority 0, new priority -19 1691: old priority 0, new priority -19 1762: old priority 0, new priority -19 2013: old priority 0, new priority -19 2164: old priority 0, new priority -19 2281: old priority 0, new priority -19 2406: old priority 0, new priority -19 2490: old priority 0, new priority -19 2558: old priority 0, new priority -19 2559: old priority 0, new priority -19 2838: old priority 0, new priority -19 3050: old priority 0, new priority -19 3056: old priority 0, new priority -19 3158: old priority 0, new priority -19
After flipping back to my vmstat log tty, I found that vmstat had segfaulted instead of run, I didnt see it because I ran it in the background and ran a tail of the file it was supposed to log to. I'm using procps 2.0.7 as distributed in RH8.0, which I assume is too old a version. I attached an strace of it running if anyone is curious.
To give an example ofhow intermitently slow this is, I took one of my reniced aterms, and tried running aterm with the options I usually use. I started another instance of aterm elsewhere, and in my current terminal, I ran the following:
alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e exit
real 0m0.924s user 0m0.017s sys 0m0.014s alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e exit
real 0m4.895s user 0m0.018s sys 0m0.018s alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e exit real 0m1.436s user 0m0.014s sys 0m0.018s alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e exit
real 0m0.797s user 0m0.017s sys 0m0.017s alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e exit
real 0m1.122s user 0m0.017s sys 0m0.019s
I had enough time to run aterm this way about four times before I got that other instance of aterm to give me a usable prompt.
I'll go upgrade my procps so I have a working vmstat for you next time, sorry about that. Whose shall I use? (riel/rml or calahan, or both?)
-alan
> Alan Willis wrote: >> >> > Why? We are preempting during the generic file write/read routines, >> I bet, which can otherwise be long periods of latency. CPU is up >> and I bet the throughput is down, but his test is getting the >> attention it wants. >> >> I'm curious, would running contest after a fresh boot and with >> profile=2 >> provide a profile that tells exactly where time is being spent? Since >> about 2.5.45 I've had some strange slow periods, and starting aterm >> would take a while, redrawing windows in X would slow down, it 'feels' >> like my workstation becomes a laptop that is just waking up. >> Sometimes this is after only a few minutes of inactivity, or after >> switching virtual desktops in kde, or when I have alot of aterm >> instances running. > > - Run `vmstat 1', and see if the slowdowns coincide with any unusual > IO activity. > > - Could be the scheduler. Try > renice -19 $(pidof X) $(pidof aterm) $(pidof other stuff)
[unhandled content-type:application/octet-stream] | |