I recently discussed load average and linked to Neil Gunther's
detailed explanation of the metric.

http://perfcap.blogspot.com/2007/04/load-average-differences-between.html

Also one way that load average can be higher than you expect is when
your workload is bursty. If its a very steady/constant workload you
get a lower load average, for the same utilization.

Hope this helps
Adrian


On 5/15/07, Ryan Chang <[EMAIL PROTECTED]> wrote:
Hi,

I'm reading Solaris Performance and Tools by McDougall, as described in this 
book, load average can be described as the average number of runable and 
running threads. But when I ran some load test(with 2 threads) on my 
application, I found that the load average value is higher than my CPU count, 
whereas the kthr:r value shown in vmstat is always 0, and CPU utilization is 
just 77%. So, would someone tell me why does the runqueue empty when there are 
more threads than my CPU count running on my system? What's the exact 
relationship between load avg and CPU saturation? Infomation about my system is 
shown below:
#  vmstat 5
 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s3 -- --   in   sy   cs us sy id
 0 0 0 4577000 855376 52 328 0  0  0  0  0  0  0  0  0  422 9088 9331 72  6 22
 0 0 0 4577000 855376 29 203 0  0  0  0  0  0  0  0  0  413 8624 9259 72  6 22
 0 0 0 4577000 855376 49 302 0  0  0  0  0  0  0  0  0  419 8979 9347 72  6 22

# uptime
[gmpc92/root] uptime
  3:31pm  up 17 day(s),  1:12,  4 users,  load average: 3.01, 3.01, 2.98

# uname -a
SunOS gmpc92 5.10 Generic_118833-33 sun4u sparc SUNW,Netra-240

# psrinfo -pv
The physical processor has 1 virtual processor (0)
  UltraSPARC-IIIi (portid 0 impl 0x16 ver 0x34 clock 1503 MHz)
The physical processor has 1 virtual processor (1)
  UltraSPARC-IIIi (portid 1 impl 0x16 ver 0x34 clock 1503 MHz)

Thanks in advance!

Ryan


This message posted from opensolaris.org
_______________________________________________
perf-discuss mailing list
[email protected]

_______________________________________________
perf-discuss mailing list
[email protected]

Reply via email to