The classic response-time curve in Figure 9-8 highlights the differences between CPU and IO subsystems. It turns out that real Oracle systems operate somewhere between the two. The dotted line in Figure 9-8 represents an Oracle system that operates completely and only with CPU. In others words, there is no physical IO, only logical IO activity. In contrast, the solid line represents an IO-centric Oracle system. No Oracle system can operate with only IO, because there must be CPU resources consumed to run processes, which includes processing the IO once it has been read from disk.

Figure 9-9 graphically shows a system with an intense logical IO load, which consumes virtually no physical IO resources. While you can see the classic response-time curve, it is not nearly as nice and neat as the mathematics would have us believe. But this is the reality of the situation, and as they say, it is what it is. In all fairness, the graph would have looked more like a theoretical response-time curve if I gathered more samples at each workload (and plotted the averages) and increased the sample time from 120 seconds to perhaps 360 seconds or an hour. But I wanted you to see that even with limited data, the CPU subsystem does exhibit queuing theory characteristics. Every system and every load will produce a different graph, but from an abstracted view, they will have similarities, and we will use these to anticipate the impacts of our possible firefighting solutions.

Figure 9-9. Shown is an actual response-time curve based on a heavily CPU-loaded Linux Oracle Database 10g Release 2 system with a four-CPU core subsystem. The dotted line is the service time (CPU), and the solid line is the response time (CPU plus all non-idle wait time), with the difference between the two being queue time (non-idle wait time). The initial large jump in queue time occurred at 75% utilization, and the last data point occurred at 98% utilization.