Figure 3-8. Oracle uses the system call select to put a process to sleep during heavy latch contention. The Linux strace -r option shows the call time on the next line before the name of the next call. For example, the first select shown in this figure took 0.099707(s.

During the Figure 3-8 trace, you can see the select system call and its key time parameter, which was always 10240, or 10,240 ms-not exactly 10 ms, but close enough to the pseudocode. What I find more interesting is the actual sleep time is close to 10 ms, but never exactly 10 ms. The -r option of the Linux strace option, used in Figure 3-8, shows the call time at the beginning of the next line. If you look at the actual sleep time in microseconds in Figure 3-8, you will see sleep times of 99.707 ms, 99.352 ms, 10.602 ms, and 10.504 ms, and the next value is 10.562 ms. I have observed that the more intense the CPU bottleneck, the more variance in the sleep times. This is actually good news for Oracle, because in a very real way, the operating system is providing the desired randomness without Oracle needing to randomize the sleep time itself!

Latch contention affects end user application response time. Therefore, if we want to quantifiably decrease the negative impact of latch contention, we must know how Oracle records time related to latch contention. Referring to the latching pseudocode in Figures 3-6 and 3-7, there are two key time-related areas: spinning and sleeping.