Not sure why your Linux system is sluggish and not performing to its full potential? Is the CPU overloaded, is the memory almost full, or is your system’s disk having some problems? You are not alone in facing this problem. Fortunately, Linux collects enough data to analyze the root cause of slow system performance. You need to know where to look for this data. In this tutorial, we’ll take a look at some of the best tools and utilities you can use to monitor Linux system performance. Whether you are running a home computer or a production server, these tools do the job flawlessly. Let's get started!
Although GUI monitoring tools are also available, we'll focus on the command-line environment as it works in almost every scenario. Some of the tools discussed below may not come preinstalled.
Some of these tools are available on macOS as well. So, if your Mac system is slowing down, you can use them there too. Let's get started and learn to monitor a Linux system for performance.
Why System Performance Monitoring Actually Matters
When it comes to monitoring system performance, it’s not just about it being slow. Several other important factors matter.
It boils down to these four important questions.
- What's the exact problem right now? (CPU, memory, disk, or network)
- Is the detected anomaly actually a bottleneck or normal in a given situation?
- Is it going to worsen if corrective action is not taken?
- What's the root cause of this incident, and how can it be prevented from happening in the future?
System performance monitoring is not just about staring at metrics on the screen. For developers, it means analyzing and writing better and more efficient code. For home users, it means identifying limited or failing resources/hardware and taking action in a timely manner.
The Four Pillars of Linux Performance
No matter which performance problem occurs on Linux. It can be traced back to one (or more) of the following four resources:
| Resource | What It Affects | Common Symptoms |
|---|---|---|
| CPU | Processing speed, responsiveness | High load average, slow app response |
| Memory | Multitasking, caching, stability | Swapping, OOM killer, freezes |
| Disk I/O | Read/write speed, database performance | Slow file access, high wait times |
| Network | Data transfer, latency | Timeouts, packet loss, slow downloads |
The right monitoring strategy involves identifying what to monitor and then picking the right tool for the job. Let's get started!
1. CPU Monitoring: Finding What’s Eating Your Processor
Let's start with the basics and move forward.
Quick Check: top
It's one of the most popular commands every Linux user learns. Available on every distribution, this command gives you an instant snapshot of the CPU metrics.
top
Here you need to pay attention to the following three fields:
- Load average: Displays system load over 1, 5, and 15 minutes
- %CPU: Displays the processor time each process is consuming
- us / sy / id: Denotes user time, system time, and idle time
Pro Tip: Load average is more or less equal to the number of cores present in your system's processor. If it continuously displays 2x to 3x the number of cores, it's a serious bottleneck.
The Better Version: htop
It's a better version of top, and that's what pros use daily. It has color-coded output, has scrolling support, and enables you to interact with processes directly.
sudo apt install htop # Debian/Ubuntu
sudo dnf install htop # Fedora/RHEL
htop
htop gives better outputWith htop, you can do the following:
- Processes can be sorted by memory usage or CPU. Use the F6 key to use this feature.
- Use the F9 key to kill the process from within the interface.
- If required, you can see per-core CPU usage at the top.
The per-core CPU usage view gives you a clearer picture in some scenarios. For example, if a single-threaded application is putting strain on a single core, you can detect it easily through this view. It's very useful in debugging applications.
Digging Deeper: mpstat and vmstat
Instead of the current snapshot, if you are looking for historical and/or sampled data, both vmstat and mpstat are your best bet.
vmstat 2 5
vmstat gives you critical system metrics repeatedlyThis command is displaying CPU, memory, and I/O metrics every 2 seconds for up to 5 times. The first r column displays the number of processes currently waiting for CPU time. If this number is continuously higher than the total CPU cores of the processor, your system is overloaded and stuck.
mpstat -P ALL 2
This command displays CPU core usage every 2 seconds. You can easily detect overloaded cores through it. In the example shown above, you can see the stats of 4 available cores.
Finding the Actual Culprit Process
Once you are dead sure the current performance issue is related to the CPU, you can now pin down the process hogging the CPU.
ps aux --sort=-%cpu | head -10
This command displays the top 10 processes taking the most CPU time. Analyze and pick the one you want to terminate.
pidstat 2 5 -u
For a detailed time-based CPU usage analysis, use the pidstat command.
2. Memory Monitoring: RAM, Swap, and the Silent Killer
Unlike disk or network-related issues, memory issues build up silently under the hood. They appear suddenly, crashing the system and bringing it to a halt. Let's see how to detect these dreaded memory-related issues.
The Basics: free
free -h
The -h switch displays the RAM size in GB/MB for easy reading. You should concentrate on the following two values:
- available: Amount of RAM currently available for apps/processes.
- buff/cache: Disk caching is using this much of RAM. It can be released if new processes need it.
Pro Tip: If you see low 'free' memory, that's not a problem because Linux generally caches disk data aggressively. It's an 'available' memory you should concentrate on.
Watching Memory in Real Time
watch -n 2 free -h
At times, you may want to monitor RAM usage in real time. Use the watch command. In this example, we're getting RAM usage stats every 2 seconds.
Is Your System Swapping?
Extensive swapping activity clearly indicates your Linux system's RAM is experiencing pressure. Here's how to check it:
swapon --show
vmstat 1 5
In the vmstat command output, pay attention to the values of the si and so columns. If both columns continuously show values above zero, frequent data exchange is happening between RAM and disk. This significantly slows down the system.
Finding Memory-Hungry Processes
ps aux --sort=-%mem | head -10
If you want a more human-readable and interactive output format, use the htop command discussed earlier. Use the toggle key F6 to switch between CPU and memory-based sorting.
Checking for OOM (Out of Memory) Killer Activity
If you notice that some of the processes are unexpectedly terminating, most probably the kernel’s OOM killer is in action.
dmesg | grep -i "out of memory"
journalctl -k | grep -i "killed process"
If you see this output from these commands, it clearly shows that either the RAM is on the verge of exhaustion or one or more processes are leaking memory.
3. Disk I/O Monitoring: The Bottleneck Everyone Forgets
Database and log servers often struggle with disk I/O related issues. Let's see how to monitor disk I/O activity.
Checking Disk Usage
Start by checking your system's disk capacity.
df -h
Your first goal should be to ensure there is enough free disk space for the system to function normally. Occupation of near-to-full disk capacity can give birth to different types of disk I/O related issues. First, you have to rule out this problem before moving to other disk monitoring methods.
Checking Disk Activity: iostat
sudo apt install sysstat # if not already installed
iostat -x 2 5
The following are the columns you need to pay attention to:
- %util: Denotes the percentage of time the disk was busy in fulfilling the I/O requests. If it continuously shows 100%, it means your disk is overwhelmed.
- await: Denotes the average time taken in fulfilling the I/O requests. If this is high, it means there's a long queue of requests waiting for their turn.
- r/s and w/s: Denotes reads and writes per second.
Finding Which Process Is Hammering the Disk
sudo iotop
iotopiotop is almost identical to htop and is dedicated to disk I/O request statistics. Here you can see per-process disk activity, making it easy to find out the ones overwhelming the disk.
Checking Disk Health
Remember, it's not that software is always the culprit. Sometimes, the hardware device itself is wearing off, resulting in a performance drop.
sudo smartctl -a /dev/sda
smartctl commandHere you get the SMART data of your disk. If you notice a large number of reallocated sectors, it's a clear indication that the disk is nearing the point of failure.
4. Network Monitoring: Catching Latency and Bandwidth Issues
Let's take a look at some of the tools we can use for network monitoring.
Quick Bandwidth Check: nload and iftop
sudo apt install iftop nload
sudo iftop
This gives you real-time bandwidth usage on a per-connection basis. This helps you identify the process or remote host taking up the entire bandwidth.
Checking Active Connections
ss -tulnp
If you've been using the netstat command till now, it's time to replace it with ss, which shows per-process active TCP/UDP connections. It can help you detect unexpected port access or unnatural connection counts for a process.
Testing Latency and Packet Loss
ping -c 10 8.8.8.8
mtr google.com
The mtr command combines the power of both ping and traceroute commands, enabling you to easily find out latency reasons along a network path.
Modern Monitoring: Beyond Command-Line Snapshots
Most tools discussed above are good for quick troubleshooting. But what about historical data needed for advanced optimization or problem identification that's hard to detect? Let's see how to tackle this problem.
Lightweight Local Option: sar
sar -u 1 3 # CPU usage history
sar -r 1 3 # Memory usage history
sar -d 1 3 # Disk activity history
Use the sar utility that is part of the sysstat package to log historical data for CPU, memory, and disk. It helps you analyze what happened yesterday.
Full Monitoring Stacks
For production servers handling large-scale data, full-fledged monitoring stacks should be implemented along with the use of all the tools mentioned above.
| Tool | Best For | Notes |
|---|---|---|
| Prometheus + Grafana | Metrics collection and dashboards | Industry standard, highly customizable |
| Netdata | Real-time, zero-config dashboards | Great for quick setup, very visual |
| Zabbix | Enterprise-scale monitoring | More setup overhead, powerful alerting |
| glances | Cross-platform CLI dashboard | Good middle ground between htop and full stacks |
If you don't prefer a multi-step, complex setup, go for glances for a simple yet powerful CLI-based monitoring dashboard.
sudo apt install glances
glances
glances gives you a simple yet powerful monitoring solutionThrough it, you can monitor all the critical system performance data in a nicely formatted manner within a single dashboard. I'd highly recommend trying it once.
Best Practices for Ongoing Monitoring
Before wrapping up, let's quickly take a look at the best practices to solidify our Linux system performance monitoring strategy.
- Make sure you install the
sysstatpackage on every production server. It'll ensure you can usesarto analyze historical performance data. - Always set up a basic alert for notifying when disk space consumption crosses 85% or 90%.
- If you want to frequently check performance stats on some servers, make sure you are running
glancesornetdataon them. - Always review logs through
journalctlanddmesgalong with regular performance monitoring routines. It'll help you catch errors and issues much more decisively.
Conclusion
There aren't dozens of Linux commands to memorize for performance monitoring. You just need a system for knowing which of the four big categories (CPU, memory, disk, network) to examine first, and at least one good tool for each.
Once that mental model is built, a slow system goes from a guesswork project to a 5-minute troubleshooting session. Start simple by using htop for CPU & memory, iostat & iotop for disk, ss & iftop for the network.
Add sar to track history, then bring in a dashboard if you need to monitor more than a few boxes.
Do this regularly, and you'll start catching performance issues as soon as they occur.
