Diffrence between load average and run Q

[Nicolas Dumeige]

Hello gurus,

We've made some benchmark and took some system measures.

Question : we have different figures when looking at the load average (1 min / 5 min / 15 min --> the one you have with uptime, top, ...) and the first column of the vmstat output :
procs ... ...
R B W
The "R" column.

Does anyone know what's behind the load average, is it the CPU run Q + process blocked in I/O wait, ... ?

Thanks for you help,

Nicolas

[Jeff Schussele]

Hi Nicolas,

The load avg is simply the 1 - minute load avg for all processors. As of 11i it does NOT include processes or threads waiting for disk I/O. ON 10.2 & 11.0 it DOES include them.

BUT - Don't forget to check the Priority queue as well. IF CPU is at/near 100% AND The Pri Queue is > 3, you most probably have a CPU bottleneck.

You can get VERY high run queue values, CPU at/near 100% & have absolutely NO CPU bottleneck, because the Pri Queue is at/near 0 - it's just busting ass & not knocking procs out of the CPU queue - it's just servicing them.

Rgds,
Jeff

[Nicolas Dumeige]

Jeff,

Thx for the info, but to be very specific and reformulate : why does vmstat tells me there x process in the CPU run Q when I see a work load of y for last minute ( given that x is constant during that minute).

In other word, in which way the run Q displayed by vmstat is different from the one given as an average work load ?

[D.Blond]

Hello,
Look at itrc.hp.com :



Date: 15/05/00
Document description: System Performance Tuning Guide
Document id: KBRC00000947
Good luck

[Nicolas Dumeige]

Hello,

If it's not too much to ask, can you give me the explicit href of the document ?

Thk in advance

Nicolas

[Jeff Schussele]

Hi (again) Nicolas,

I believe this is because vmstat is giving you "instant in time" snapshots whereas the load avg is a weighted average over specific time periods.
You have to remember that processes normally spend *very* little time actually in the run queue. They're either being executed or much more often - sleeping.

This is just one of the reasons that CPU bottlenecks are probably the most misdiagnosed ( i.e. mistaken for other bottlenecks) and usually the hardest to definitively pindown as to root cause (i.e. it frequently requires tusc-type tracing or even source code examination).

Rgds,
Jeff

[Nicolas Dumeige]

Jeff,

There is something odd in deed in the fact that this is the same entity that is doing the measure and be measured : it's like looking yourself walking ! So, waht I'm saying is that I'm aware of the difficulty of resource accounting.

But, at the end, both tool depend on the structures maintained by the kernel ?

Subsidiary question : what result would you value most ?

Best regards,

Nicolas

[Jeff Schussele · Accepted solution]

Frankly, you need *more* than one tool usually.
I use a combo of glance/gpm, sar AND vmstat along with the uptime/top stats.
But I probably rely on glance/gpm the heaviest as you can really drill down with it.

Rgds,
Jeff