Archives of the TeradataForum

Message Posted: Fri, 24 Aug 2001 @ 18:36:30 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

I don't have a better explanation for User Service Time, but you can do as well by thinking about the fact that summing User Service Time and User Exec Time should pretty much equal the total time in which the CPU is busy.

So where User Exec Time reflects the amount of time in which the CPUs are busy in User State working on a process, User Service Time reflects the amount of time in which these same CPUs are busy performing system services (eg- overhead). So combined, they represent the average CPU busy time (user work busy + system services busy).

I tend to prefer using the ResUsage tables directly and not the macros. To start, the values contained in RESUSAGESPMA are aggregations at the Node level (there are four Processors on a Node), for the duration of a sampling interval. You need to keep this in mind because you'll have to do a little arithmetic to make the values meaningful. For example, to get the average CPU Busy (combining Services and User Exec) time for a sampling period:

(CPUUSERV + CPUUEXEC) / NULLIFZERO(VAPPS) / SEC

User Service Time can be traced back to RESUSAGESPMA.CPUUSERV and User Exec Time traces back to RESUSAGESPMA.CPUUEXEC. In table RESUSAGESPMA there are two other columns that you need to consider:

Column CPUIDLE indicates the amount of time that the CPU is idle and not waiting for I/O.

Column CPUSYSOH indicates the amount of time that the CPU is idle and waiting for the completion of an I/O operation.

Summing CPUIDLE and CPUSYSOH should give the average of the time that the CPU is not busy - or time in which the CPUs are idle or waiting on I/O.

So the following:

(CPUIDLE + CPUSYSOH + CPUUSERV + CPUUEXEC) / NULLIFZERO(VAPPS) / SEC

should give a value close to 100% of the time. I should mention that I don't have a machine currently available and I can't actually test the above, but I'm reasonably confident.

Using my own experience (and point of view), I would take the idea of using CPU Busy to try and determine if you can add more work with a grain of salt. If there is work to do and if there was no such thing as having to wait on I/O, then the machine should always be 100% busy. The thing that keeps you from keeping your machine 100% busy (at all times) is that the CPU spends a lot of time waiting on I/O and overhead.

So when looking at how busy your CPUs are, you really should consider all four of the CPU values from RESUSAGESPMA. Comparing all four should give you a pretty good picture of when the machine is largely idle versus busy, but you'll have to consider include additional columns to see if there are saturation issues and from my point of view, it's saturation that limits the actual amount of work that your machine can do.

	<Prev	Next>		<<First	<Prev	Next>	Last>>