Re: high load ?

[Shachar Shemesh]

Yedidyah Bar-David wrote:
You may have to tweak the numbers a bit, but it seems about right. A 
different question is whether, under this scenario, the load average is 
still the right metric to look at? I think it is. If the load average is 
2, my shell still have quite a queue to wait for being actively 
processed, and the responsiveness will depend on the time slices alloted 
to each process.
   

This is so only if you have load only on the CPU.
I'm sorry, I don't see how the number of CPUs enter into it. I'm not 
sure whether the load average should be divided by the number of CPU's 
or not in order to get a consistent number, but that's besides the 
point. I was merely trying to show a situation in which the CPU is 
relatively idle, but the load average is high, and then ask whether we 
are still more interested in the load or the idle time.

If, for example, you
only have one process running, but which does a lot of paging, your
load average will be <=1, but the responsiveness will be quite bad,
as your shell will probably be paged out when you press a key.
 

Not if I repeatedly hit keys. That said, obviously both load average and 
CPU state are CPU metrics. Total system performance is affected by other 
factors, such as disk speed, memory usage, network latency etc. These 
are not reflected in the load average at all. If a process is waiting 
for disk or network it won't be in the "Ready" queue. I'm not sure about 
swap though. As for CPU stats, it may be somewhat reflected in the 
amount of time the CPU spent in system vs. user, but not in the idle count.

OTOH, today's CPU are very fast, and in most cases, if you run a few
'for (;;);' in the background, an interactive shell user won't notice,
while the load average will equal the number of such loops.
 

What does CPU speed have to do with it? A faster CPU will perform many 
more no-op loops than a slow one, but would still take 100% CPU. The 
scheduler today may be smarter and give my shell a higher priority due 
to its interactiveness, but that, again, has nothing to do with the 
CPU's speed. It seems to me that the only thing related to speed 
affecting the perceived responsiveness of my shell is going to be the 
time slice alloted to each running process.

Much more annoying for our own users is amd mounts that sometimes take
a lot of time or stuck. I know this isn't kernel-related, but it does
hurt a lot responsiveness.
 

A. See above for non-CPU related problems.
B. I know that the NFS code used to have TONS of locks held for far far 
far too long. Any network latency spewed processes in "D" state by the 
bucket load. That is very much kernel related. I don't know how things 
are today.

I personally do not know any single number that can tell on unix what
the expected responsiveness is.
 

RTFM time(1)
         Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]