DBAs who have control over the workload entering their system have been known to run the CPUs as busy right up to the beginning of the elbow of the curve. Now, not many administrators have this kind of workload control. But if your system runs a combination of online transaction processing (OLTP) and batch processes, then it's likely you can play this game yourself. Let's look at how.

If your system is more of an OLTP system or more batch-centric, you have some creative choices to maximize your user's experience. For an OLTP system, users want snappy response time. They really don't care about how much work the system is processing, but just want the system to be responsive to their requests. On the other hand, if the focus is on batch processing, responsiveness takes a backseat to throughput. For example, if there are 12 CPU cores along with a long batch process queue, having a CPU idle is something we don't want to see. Let's take this a step further.

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.