How to monitor high CPU, memory, and load average usage in Linux [Linux]

When troubleshooting a slow Linux system, two of the most common culprits are high CPU usage and memory pressure. Alongside these, the load average provides valuable insight into how busy your system is. Understanding how to check these metrics and interpret them correctly is essential for diagnosing performance issues.

In this guide, we’ll cover step-by-step how to use commands like top and ps to identify resource-hungry processes, and how to interpret the load average. By the end, you’ll be able to spot which processes are causing slowdowns and decide what action to take.

Step-by-Step Guide:

Checking CPU and Memory Usage with top

The top command provides a real-time view of what’s happening on your system.

$ top

Key sections to focus on:

• %Cpu(s): Shows CPU usage breakdown. High user (us) or system (sy) percentages indicate a heavy workload.
• Mem & Swap: Displays memory and swap usage. If swap usage is high, your system is running out of RAM.
• Process list: At the bottom, you’ll see processes consuming resources. By default, it’s sorted by CPU usage.

Pro tip: While inside top, press Shift+M to sort by memory usage, or Shift+P to sort by CPU.

Using ps to List High Resource Processes

The ps command is another handy tool for listing processes, and it’s especially useful when combined with sorting options.

Processes consuming the most memory:

$ ps -eo pid,comm,%mem,%cpu --sort=-%mem | head -10

This shows the top 10 processes by memory usage.

Processes consuming the most CPU:

$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -10

Columns explained:

• pid → Process ID
• comm → Command (program name)
• %mem → Memory usage percentage
• %cpu → CPU usage percentage

List the top 10 processes consuming the most memory, with usage displayed in MB:

$ ps aux | grep -v grep | awk '{print $6/1024 " MB\t\t"$11;}' | sort -n | tail -10

 

Understanding Load Average

The load average tells you how many processes are waiting for CPU time. You’ll see it in the output of top, uptime, or w:

$ uptime

$ w

Example output:

17:03:14 up 2 days,  4:51,  2 users,  load average: 0.80, 1.05, 0.98

The three numbers represent the average system load over the last 1, 5, and 15 minutes.

How to interpret:

A load average of 1.00 means one process is running or waiting for CPU. If you have a single-core CPU, values consistently above 1.00 mean the system is overloaded. For a 4-core CPU, a load average of 4.00 means full utilization.

Rule of thumb: Compare load average to the number of CPU cores (nproc shows how many you have).

 

Additional Useful Commands

free -h → Check memory and swap usage in a human-readable format.

vmstat 5 → Monitor processes, memory, paging, block I/O, and CPU activity every 5 seconds.

htop (if installed) → A friendlier, colorful alternative to top with easier navigation.

 

Conclusion

Monitoring system performance in Linux doesn’t need to be complex. With just a few commands—top, ps, and uptime—you can quickly determine whether high CPU, memory, or load average is slowing down your system.

By regularly checking these metrics, you’ll be able to:

• Identify which processes are consuming the most resources
• Understand whether your system is overloaded
• Take action to optimize or terminate resource-heavy processes

Mastering these tools is an essential skill for any Linux user, whether you’re managing a personal server or working in production environments.

References/Related Content 

• Top: https://man7.org/linux/man-pages/man1/top.1.html
• Ps: https://www.man7.org/linux/man-pages/man1/ps.1.html
• Free: https://man7.org/linux/man-pages/man1/free.1.html
• Uptime: https://man7.org/linux/man-pages/man1/uptime.1.html
• W https://man7.org/linux/man-pages/man1/w.1.html
• Vmstat: https://www.man7.org/linux/man-pages/man8/vmstat.8.html
• Load average: https://www.digitalocean.com/community/tutorials/load-average-in-linux

Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.