CPU scheduling parameters

In this topic, let's discuss a few CPU scheduling parameters, which will fine tune the scheduling policy.

Getting ready

In the previous recipe, we discussed memory-related parameters, which are not sufficient for better performance. Much like memory, kernel also supports various CPU-related tuning parameters, which will drive the processes scheduling.

How to do it...

Let us discuss about, few major CPU kernel scheduling parameters in Linux:

kernel.sched_autogroup_enabled

This parameter groups all the processes that belong to the same kernel session ID, which are further processed as a single process scheduling entity rather than multiple entities. That is, the CPU will indirectly spend a contiguous amount of time on a group of processes that belong to the same session rather than switching to multiple processes. Using the ps xa -o, sid, pid, and comm command, where we can get the session ID of the processes. It is always recommended to set this value to 0 for the PostgreSQL standalone server, as each process belongs to a unique session ID.

kernel.sched_min_granularity_ns

This parameter defines the minimum time slice of the process that it needs to spend in the allocated CPU before its preemption. The recommended value for this parameter is 2,000,000 ns, and it can be tuned further by doing proper benchmarking with multiple settings.

kernel.sched_latency_ns

This parameter defines the kind of maximum time slice for each process that runs in CPU core. However, this process time slice will be calculated based on the load at that time in the server; it also includes the process's nice values along with the sched_min_granularity_ns parameter. The recommended value for this parameter is 10,000,000 ns, which gives better performance for the moderated number of process. If the database server is dealing with more processes, this setting may lead to more processes preemption and may reduce the performance of the CPU-bound tasks.

kernel.sched_wakeup_granularity_ns

This parameter defines whether the current running process needs to be preempted from the CPU, when it compares its vruntime (virtual run time of the process, that is, the actual time the process spends in CPU) with the woken process vruntime. If the delta of vruntime between these two processes is greater than this granularity setting, then it will cause the current process to preempt from the CPU. The recommended value for this parameter should always be less than half of the sched_latency_ns.

kernel.sched_migration_cost_ns

This parameter defines the amount of time in which the process is ready for the CPU migration. That is, after spending this much amount of time, a process is eligible to migrate to another CPU core, which is less busy. By reducing this value, the scheduler makes more task migrations among the CPU, which will effectively utilize all the cores. But migrating a task from one CPU to another requires additional efforts, which may reduce the performance of the process. The recommended value for this parameter is 500,000.

How it works...

In the Linux kernel, each process is called a kernel scheduling entity (KSE), which will be processed based on different scheduling policies. Using the preceding parameters, we can control the process scheduling and migration of the process among CPUs, which will improve the execution speed of a process. We can also process a set of processes as a single KSE by using the sched_autogroup_enabled option, where a set of processes will get more CPU resources than the others.