views:

155

answers:

1

Does anyone know an elegant way to determine “System Load” preferably using Windows performance counters? In this case I mean “System Load” in the classical (UNIX) sense of the term and not in the commonly confused “CPU Utilization” percentage.

Based on my reading … “System Load” is typically represented as a float, defining the number of processes in a runnable state (i.e. not including the number of processes that are currently blocked for one reason or another) that could be run at a given time. Wikipedia gives a good explanation here - http://en.wikipedia.org/wiki/Load_(computing).

By-the-way I’m working in C# so any examples in that language would be greatly appreciated.

+3  A: 

System load, in the UNIX sense (and if I recall correctly), is the number of processes which are able to be run that aren't actually running on a CPU (averaged over a time period). Utilities like top show this load over, for example, the last 1, 5 and 15 minutes.

I don't believe this is possible with the standard Win32 WMI process classes. The process state field (ExecutionState) in the WMI Win32_Process objects are documented as not being used.

However, the thread class does provide that information (and it's probably a better indicator as modern operating systems tend to schedule threads rather than processes). The Win32_Thread class has an ExecutionState field which is set to one of:

  • 0 Unknown
  • 1 Other
  • 2 Ready
  • 3 Running
  • 4 Blocked
  • 5 Suspended Blocked
  • 6 Suspended Ready

If you were to do a query of that class and count up the number of type 2 (and possibly type 6; I think suspended means swapped out in this context), that should give you your load snapshot. You would then have to average them yourself if you wanted averages.

Alternatively, there's a ThreadState in that class as well:

  • 0 Initialized (recognized by the microkernel).
  • 1 Ready (prepared to run on the next available processor).
  • 2 Running (executing).
  • 3 Standby (about to run, only one thread may be in this state at a time).
  • 4 Terminated (finished executing).
  • 5 Waiting (not ready for the processor, when ready, it will be rescheduled).
  • 6 Transition (waiting for resources other than the processor).
  • 7 Unknown (state is unknown). so you could look into counting those in state 1 or 3.

Don't ask me why there's two fields showing similar information or what the difference is. I've long since stopped second-guessing Microsoft with their WMI info, I just have to convince the powers that be that my choice is a viable one :-)

Having just finished developing a Windows client for our own monitoring application, I'd just suggest going for 1-second snapshots and averaging these over whatever time frame you need to report on. VBScript and WMI seem remarkably resilient even at one query per second - it doesn't seem to suck up too much CPU and, as long as you free everything you use, you can run for extended periods of time.

So, every second, you'd do something like (in VBScript, and from memory since I don't have ready access to the code from here):

set objWmi = GetObject("winmgmts:\\.\root\cimv2")
set threadList = objWmi.ExecQuery("select * from Win32_Thread",,48)
sysLoad = 0
for each objThread in threadList
    if objThread.ThreadState = 1 or objThread.ThreadState = 3 then
        sysLoad = sysLoad + 1
    end if
next
' sysLoad now contains number of threads waiting for a CPU. '
paxdiablo
Pax - thanks for the answer this helps a lot. I do have one follow-up question however, if I recall correctly load when shown with systems like "top" represents the value as a float (ie 1.35 or 5.45). In your example you would only ever get whole numbers for the system load. Any idea where the fractional values come into plat?
Never mind ... my stupid ... those values are the averages over 1, 5 and 15 minutes. For some reason I kept thinking that the first value was really a single point in time not an average over a small period.