Stop guessing what’s slowing down Linux. Do this instead
With Linux, especially if you’re new, it can be confusing when the operating system slows down, seemingly out of the blue. This can happen with any operating system, but you may know how to identify it on Windows, but not on Linux.
It can be intimidating, but it’s easy. Here’s how.
Get the big picture (htop)
When a Linux system starts crawling, your first instinct is often to start killing processes or restarting completely. However, the most effective approach begins with obtaining a comprehensive, real-time overview of system status. The tool of choice for this initial assessment is htop, an interactive process viewer that replaces the classic top command in a modern and user-friendly way.
Launching htop instantly presents a visual dashboard divided into two main sections. The top section displays critical resource usage via color-coded bar charts, illustrating current load on individual CPU cores, physical memory allocation, and swap space usage. These visual indicators allow administrators to immediately recognize whether the processor is stuck at maximum capacity or whether the system is aggressively paging memory to disk.
The bottom half provides a dynamic, scrolling list of all running processes, updating every few seconds. Unlike older utilities, htop allows users to scroll vertically to view all processes and horizontally to see full command lines, which is crucial for identifying specific applications causing problems.
7 Things Nobody Tells You About Dual Booting Linux and Windows
The truths about dual booting I learned the hard way.
Additionally, the interface supports transparent sorting. By simply pressing a dedicated function key or clicking with a mouse, an administrator can organize the list of processes by CPU consumption, memory footprint, or execution time.
This holistic view eliminates the guesswork inherent in isolated controls, providing a centralized control panel to monitor exactly how system resources are distributed at any time.
Identify the bottleneck
Find out what’s causing so much trouble
Now that you have done this, the next critical phase is to identify the specific bottleneck limiting system performance. A bottleneck occurs when the demand for a particular system resource exceeds its available capacity, forcing processes to queue and wait, thereby slowing down the entire operating system. In Linux environments, performance degradation can almost universally be attributed to one of four major subsystems: the CPU, physical memory, disk I/O, or network interface.
Identifying the bottleneck requires analyzing the symptoms observed during the initial overview of the system. If all processor cores are consistently running at full capacity, the system is compute-limited, indicating that an application requires more processing power than the hardware can provide. Conversely, if physical memory is exhausted and the system starts using swap space massively, it becomes memory-limited.
This condition, known as thrashing, is particularly devastating to performance because disk access is exponentially slower than RAM access. However, one of the most common and often misdiagnosed bottlenecks is disk I/O. A system can have surprisingly low CPU usage and have a lot of free memory, yet still be incredibly slow. In these cases, it is essential to check the average system load.
An average load significantly higher than the number of available CPU cores, combined with a high percentage of CPU wait time, strongly suggests that processes are stuck waiting for the storage drive to read or write data. By carefully evaluating these interconnected metrics, administrators can isolate the failing pillar. Isolating the bottleneck is the dividing line between amateur guessing and professional administration, because it dictates exactly which specialized diagnostic tool should be deployed next to find the exact root cause.
Get a specific diagnostic (iotop, vmstat, others)
Deploy the actual fix
Lucas Gouveia/How to Geek
Once the general bottleneck category is identified, administrators must deploy specialized, granular tools to extract a specific diagnosis. If the system is suffering from disk I/O exhaustion, iotop is the definitive utility to discover the culprit.
Working much like a traditional process monitor, iotop specifically isolates storage activity, displaying real-time read and write speeds categorized by individual processes and threads. This immediately exposes runaway writers, heavy database queries, or backup scripts that are hogging the storage controller.
For deeper investigations into memory constraints and CPU scheduling, vmstat provides invaluable historical context. Running vmstat with a specified delay interval generates continuous lines of system metrics, allowing administrators to observe trends over time rather than just a snapshot. The swap columns in vmstat are particularly diagnostic; Sustained high numbers in the swap-in and swap-out fields confirm severe memory starvation and active thrashing. Additionally, the CPU wait column in vmstat definitively proves whether CPU cycles are wasted waiting for response from block devices. If the bottleneck has been attributed to the network interface, utilities such as iftop or nethogs serve a similar purpose, breaking down bandwidth consumption by connection or by individual process to reveal data hogging or potential denial of service attacks.
Deploying these highly specialized tools turns a vague symptom, like a slow server, into a concrete, actionable diagnosis. By identifying the exact process ID, command line argument, or specific hardware limitation responsible for the performance degradation, system administrators can take precise action.
