Too Much Context Switching
Learn what context switching is, how to monitor it, and how it can become an issue. We will go over context switching in real-time systems and typical Linux servers.
Table of Contents 📖
Context Switching
Context switching is a process where the operating system saves the state of a currently running process and loads the state of another process so that the CPU can execute it. This process involves saving and restoring registers, program counters, and memory mappings. An easy way to monitor context switching is with the vmstat command below:
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 0 123456 78901 123456 0 0 0 0 123 456 10 5 85 0
- vmstat - Provides real-time system performance statistics
- 1 - The number specifies the interval (in seconds) at which the stats should refresh. In this case, it updates every second.
- cs (Context switches) - Number of context switches per second.
Too Much Context Switching
Excessive context switching can lead to performance bottlenecks and system inefficiencies as, while each context switch takes a small amount of time, it introduces overhead, as the CPU is not doing "useful" work during this transition.
WARNING: The higher the frequency of context switches, the more CPU time is wasted managing tasks rather than executing them. In other words, when context switches become excessive, the CPU spends more time saving and loading states rather than executing processes.
The threshold for "too many" context switches depends on the system and its workload. For example, on a typical Linux server, context switch rates of a few thousand per second are normal under moderate workloads. However, on a real-time system, even small delays caused by context switching can be unacceptable. In such cases, a few hundred switches per second might be too high.
Reducing Context Switching
One way to reduce excessive context switching is to optimize thread and process management. In other words, use thread pools to manage worker threads efficiently and avoid creating too many processes or threads unnecessarily. For example, Node allows us to set the size of its thread pool using the environment variable UV_THREADPOOL_SIZE. Don't set it to a number that is too high.
UV_THREADPOOL_SIZE=8 node app.js
On an operating system level, you can even fine tune the OS scheduling policies to reduce unnecessary switches (such as increasing process timeslices).