Section 7.1. Operating System Process Management
 |
7.1 Operating System Process Management
From the perspective of your system's host operating system, the Oracle kernel is just an application. There's nothing mystical about how it works; it's just a huge, extremely impressive C program. To gain a full appreciation for the operational timing data that the Oracle kernel reveals, you need to understand a little bit about the services an operating system provides to the Oracle kernel.
In this section, I am going to focus my descriptions on the behavior of operating systems derived from Unix. If your operating system is a Unix derivative like Linux, Sun Solaris, HP-UX, IBM AIX, or Tru64, then the explanations you will see here will closely resemble the behavior of your system. You should find the descriptions in this section relevant even if you are studying a Microsoft Windows system. If your operating system is not listed here, then I suggest that you augment the descriptions in this section with the appropriate operating system internals documentation for your system.
The Design of the Unix Operating System , written by Maurice Bach, contains what is still my very favorite tool for describing what a process "does" in the context of a modern operating system. Bach's Figure 2-6, entitled "Process States and Transitions" [Bach 1986 (31)], serves as my starting point. I have reproduced it here as Figure 7-1. In this diagram, each node (rectangle) represents a state that a process can take on in the operating system. Each edge (directed line) represents a transition from one state to another. Think of states as nouns and transitions as verbs that motivate the passage of a process from one state to the next .
Figure 7-1. This simplified process state diagram illustrates the principal states that a process can assume in most modern time-sharing operating systems [Bach (1986) 31]
Most Oracle kernel processes spend most of their time in the user running state, also called user mode . Parsing SQL, sorting rows, reading blocks in the buffer cache, and converting data types are common operations that Oracle executes in user mode. There are two events that can cause a process to transition from the user running state to the kernel running state (also called kernel mode ). It is important for you to understand both transitions from user mode to kernel mode. Let's follow each one in more detail.
7.1.1 The sys call Transition
When a process in user mode makes an operating system call (a sys call ), it transitions to kernel mode. read and select are two typical system calls. Once in kernel mode, a process is endowed with special privileges that allow it to manipulate low-level hardware components and arbitrary memory locations. In kernel mode, a process is able, for example, to manipulate I/O devices like sockets and disk drives [Bovet and Cesati (2001) 8].
Many types of system call can be expected to wait on a device for many, many CPU cycles. For example, a read call of a disk subsystem today typically consumes time on the order of a few milliseconds . Many CPUs today can execute millions of instructions in the time it takes to execute one physical disk I/O operation. So during a single read call, enough time to perform on the order of a million CPU instructions will elapse. Designers of efficient read system calls of course realize this and design their code in a manner that allows another process to use the CPU while the read ing process waits.
Imagine, for example, an Oracle kernel process executing some kind of read system call to obtain a block of Oracle data from a disk. After issuing a request from an expectedly "slow" device, the kernel code in the read system call will transition its calling process into the sleep state, where that process will await an interrupt signaling that the I/O operation is complete. This polite yielding of the CPU allows another ready to run process to consume the CPU capacity that the read ing process would have been unable to use anyway.
When the I/O device signals that the asleep process's I/O operation is ready for further processing, the process is "awoken," which is to say that it transitions to ready to run state. When the process becomes ready to run, it becomes eligible for scheduling. When the scheduler again chooses the process for execution, the process is returned to kernel running state, where the remaining kernel mode code path of the read call is executed (for example, the data transfer of the content obtained from the I/O channel into memory). The final instruction in the read subroutine returns control to the calling program (our Oracle kernel process), which is to say that the process transitions back into user running state. In this state, the Oracle kernel process continues consuming user-mode CPU until it next receives an interrupt or makes a system call.
|
7.1.2 The interrupt Transition
The second path through the operating system process state diagram is motivated by an interrupt . An interrupt is a mechanism through which a device such as an I/O peripheral or the system clock can interrupt the CPU asynchronously [Bach (1986) 16]. I've already described why an I/O peripheral might interrupt a process. Most systems are configured so that the system clock generates an interrupt every 1/100 th of a second (that is, once per centisecond). Upon receipt of a clock interrupt, each process on the system in user running state saves its context (a frozen image of what the process was doing) and executes the operating system scheduler subroutine. The scheduler determines whether to allow the process to continue running or to preempt the process.
Preemption essentially sends a process directly from kernel running state to ready to run state, clearing the way for some other ready to run process to return to user running state [Bach (1986) 148]. This is how most modern operating systems implement time-sharing. Any process in ready to run state is subject to treatment that is identical to what I have described previously. The process becomes eligible for scheduling, and so on. Your understanding of preemptions motivated by clock interrupts will become particularly important later in this chapter when I describe one of the most important causes of "missing data" in an Oracle trace file.
7.1.3 Other States and Transitions
I have already alluded to the existence of a more complicated process state transition diagram than I've shown in Figure 7-1. Indeed, after discussing the four process states and seven of the transitions depicted in Figure 7-1, Bach later in his book reveals a more complete process state transition diagram [Bach (1986) 148]. The more complicated diagram details the actions undertaken during transitions such as preempting, swapping, forking, and even the creation of zombie processes. If you run applications on Unix systems, I strongly encourage you to add Bach's book to your library.
For the purposes of the remainder of this chapter, however, Figure 7-1 is all you need. I hope you will agree that it is easy to learn the precise definitions of Oracle timing statistics by considering them in terms of the process states shown in Figure 7-1.
| |
| Top |
EAN: 2147483647
Pages: 102