Process Management

An enterprise database server can have thousands of users accessing the database concurrently. Some users might perform simple transactions that require little processing power, whereas others might perform complex transactions that require much more system resources. Database performance is often discussed in terms of metrics such as transactions per hour or minimum response time with X number of current connections. These performance constraints are imposed by businesses to ensure a level of quality assurance for the customer. With such a high demand on concurrent processing, an enterprise database server needs to run on large SMP servers.

Early Linux kernels were not well suited for use as database servers requiring a high degree of concurrency. These kernels did not scale well as the number of processors on the system increased because early kernel developments were driven by single-processor machines. Migration to a multiprocessor platform exposed many global kernel locks, which can cause serialization problems. The largest of these global locks is a spin lock protecting a single unordered run queue. In a single-processor environment, a single queue is sufficient to handle the scheduling of all runnable tasks. However, in an SMP environment, a single run queue is inadequate and can become a bottleneck. As the number of processors increases, the potential for lock contention on the run queue also increases. Furthermore, because the queue is unordered, the scheduler has to examine every task in the queue while the lock is held to determine the goodness of the tasks. (Each task is assigned a goodness value, which is used to determine which task is the best candidate to be scheduled to run on a processor.) This increases the lock hold time, which increases the chances of lock contentions or exacerbates current contention conditions. In the 2.5 kernel, the single run queue is removed and replaced with per-CPU run queues. Having multiple run queues removes the single global lock and improves overall scalability. In addition, each run queue maintains a priority list, which helps the scheduler pick the best task to run. This prioritization reduces the lock hold time on the queue and further reduces lock contentions.