How to monitor Linux server performance: commands, metrics and tools

To monitor Linux server performance, check four resources: CPU, memory, disk I/O and network. Use built-in commands such as top, vmstat, free, iostat and ss for live troubleshooting, and an agent-based tool such as Prometheus with node_exporter, Zabbix or the CloudWatch agent to store history and send alerts.

Key takeaways

• For each resource, check utilisation, saturation and errors (the USE method). High utilisation alone is not a problem; queues and errors are.
• Compare load average with the number of CPU cores, and watch %wa (I/O wait) and %st (steal time) on cloud VMs.
• For memory, read the available column of free, not free. Linux uses spare memory as cache on purpose.
• Pressure stall information in /proc/pressure/ shows directly how much time tasks wait for CPU, memory or I/O.
• Commands show the present. For trends and alerts you need a monitoring agent and a time-series store.

Which Linux performance metrics matter?

Start with the USE method by performance engineer Brendan Gregg: for every resource, check utilisation, saturation and errors. It gives you a checklist instead of guesswork.

How do you check CPU usage and load on Linux?

Run top (or htop) and read the CPU line, then compare the load average with the number of cores from nproc.

top # live view; press 1 to show each core
nproc # number of CPU cores
uptime # load average over 1, 5 and 15 minutes
mpstat -P ALL 1 # per-core usage every second (sysstat package)

According to the proc_loadavg man page, load average counts jobs that are running or waiting for disk I/O, averaged over 1, 5 and 15 minutes. A load of 6 on an 8-core server is fine. A load of 6 on a 2-core server means work is queuing. Because load includes processes waiting for disk, a high load with low CPU use usually points to a storage problem.

In the top CPU line, two fields matter on cloud servers:

• wa: time the CPU sat idle waiting for I/O. Sustained high values point to slow disks or network storage.
• st: per the top man page, "time stolen from this vm by the hypervisor". Sustained steal on a cloud VM means the host is busy or a burstable instance has run out of CPU credits.

How do you check memory usage on Linux?

Run free -h and read the available column. The free man page defines it as an estimate of memory available for new applications without swapping, taking page cache into account.

free -h # human-readable memory summary
vmstat 1 5 # si/so columns show swap in/out per second
journalctl -k | grep -i "out of memory" # OOM killer events

A server with little "free" memory but plenty "available" is healthy: Linux fills spare RAM with disk cache and releases it when programs need it. Warning signs are falling available memory over days (a possible leak), constant swap activity in vmstat, and OOM killer entries in the kernel log.

How do you check disk performance and space?

Use iostat -xz 1 for I/O performance, and df for space and inodes.

iostat -xz 1 # per-device utilisation, queue and latency (sysstat)
df -h # disk space per filesystem
df -i # inode usage: many small files can fill these first
du -sh /var/log/* | sort -h # find what is using space

In iostat, watch r_await and w_await (average milliseconds per request) and aqu-sz (queue length). The iostat man page notes that for devices serving requests in parallel, such as RAID arrays and modern SSDs, %util does not reflect their performance limits. Rising latency and queue length are better signs of saturation.

How do you monitor network performance?

sar -n DEV 1 # throughput per interface
sar -n TCP,ETCP 1 # TCP connections and retransmits
ss -s # socket summary
ip -s link # errors and drops per interface

Rising retransmits, drops or interface errors indicate network problems even when throughput looks normal. On cloud VMs, compare throughput with the instance type's network limit.

What is pressure stall information (PSI)?

PSI is a kernel feature that reports how much time tasks spend waiting for CPU, memory or I/O. The kernel documentation explains that each file in /proc/pressure/ has a "some" line (share of time at least some tasks are stalled) and, for memory and I/O, a "full" line (all non-idle tasks stalled at once, which the kernel describes as thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI answers "is this resource slowing work down?" directly, which makes it a good alerting signal. If the files do not exist, your kernel was built or booted without PSI support.

Which tools should you use for continuous monitoring?

Commands show what happens now. To catch problems at night, see trends and alert the right person, install a monitoring agent that ships metrics to a time-series store.

Which alerts should you set first?

1. Disk space and inodes above 80–85% on any filesystem, with a forecast alert for "full within 24 hours".
2. Available memory low for more than 10 minutes, or any OOM killer event.
3. Load average above the core count for more than 15 minutes, or CPU pressure rising.
4. Disk latency or I/O pressure well above the server's normal baseline.
5. Service checks: the application port answers and a health URL returns success.
6. Backups and certificate expiry, which fail quietly.

These thresholds are starting points. Tune them to each server's normal behaviour so alerts stay actionable. Our guide to monitoring server performance covers Windows and general practice, and monitoring cloud infrastructure covers managed services beyond the server.

How Opsio helps

Opsio monitors and operates Linux servers on AWS, Azure and on-premises as part of our managed IT services, including 24/7 alert response, patching and capacity reviews, with Prometheus and Grafana or cloud-native tooling. For example, the AWS platform we built for WorkBuster runs on EC2 instances in an auto-scaling group, with CloudWatch dashboards and alarms for day-to-day operations.

Frequently asked questions

What is the best command to check Linux server performance?

Start with top for a live overview, then vmstat 1 for CPU, memory and swap trends, and iostat -xz 1 for disks. Together they show most bottlenecks within a minute.

What is a good load average for a Linux server?

It depends on the number of CPU cores. A load average at or below the core count usually means no queuing. Sustained load above the core count means tasks are waiting for CPU or disk.

Why does Linux show almost no free memory?

Linux uses unused RAM as disk cache and gives it back when applications need it. Check the available column of free -h instead; that is the memory actually available for new work.

How do I see which process is using the most CPU or memory?

In top, press P to sort by CPU and M to sort by memory. From a script, use ps aux --sort=-%cpu | head or ps aux --sort=-%mem | head.

How do I monitor a Linux server remotely?

Install an agent such as node_exporter, the Zabbix agent or the CloudWatch agent, and send metrics to a central server or cloud service. That gives you history, dashboards and alerts without logging in to each machine.

Related reading: Linux Support Services.