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.

Figure 9-10 graphically shows a system with an intense physical read IO load. Because the system is experiencing a heavy physical IO load, the response-time curve is likely to correlate with physical IO-related statistics. For this figure, I chose the instance statistic physical reads.4 The service time metric is the sum of the time model statistics DB CPU for server process CPU time and background cpu time for the background process CPU time.5 The queue time consists of all non-idle wait event time. With only these simple time classifications, the graph in Figure 9-10 was created. As you'll see later in the chapter, we can use graphs like this to anticipate our solution's impact.