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.

The arrival rate in Figure 9-9, which is the horizontal axis, is simply the number of logical IOs (v$sysstat: buffer gets plus consistent gets) processed per millisecond. The service time was calculated by dividing the total service time (v$sys_time_mode: DB CPU plus background cpu time) by the total number of logical IOs. The queue time was calculated by dividing all non-idle wait time by the number of logical IOs. From a mathematical perspective, the data collection interval is irrelevant as long as all the data is gathered during the same interval. But if you are curious, the sample interval was 120 seconds.