We know that the lower the CPU busyness, the shorter the CPU queue. For a snappy OLTP system, we do not want processes waiting in the queue. We want the OLTP-related processes to be serviced immediately! The way to increase the likelihood of this occurring is to keep the CPU busyness relatively low. This means if you have an OLTP-centric system and desire snappy response time, you must keep the CPU subsystem at a low enough utilization to ensure OLTP processes are not queuing. For example, if a system is a mix of OLTP and batch processing, which most systems are, then during key OLTP processing times, you will want to throttle back batch processing to ensure the CPU run queue is not impacting OLTP processing responsiveness.

If the system is batch-centric or batch processing is the priority, the situation becomes very different. For systems focused on batch processing, service levels are not measured by response time. The key service level for batch systems is throughput; that is, response time is not based on a single batch job, but on a group of batch jobs. Put another way, throughput is important, not response time. Idle resources are death to throughput. For a batch-focused system, every bit of CPU power needs to be consumed.

The way to ensure every bit of CPU is being consumed is to ensure the CPU busyness reaches the level where there is always a process waiting in be serviced. Said another way, make sure there is always a process queued up and ready to run. So for a batch-centric system, you will want to run the CPU busyness at a much higher level than you would for an OLTP-centric system.