Linux Check CPU Usage: top, htop, mpstat

If you need a fast Linux check CPU usage workflow, start with top, use htop when you want an easier interactive view, and use mpstat when you need per-core or interval data. Those three tools answer slightly different questions, so the safest approach is to choose the tool based on the problem you are investigating.

On a VPS, CPU usage is not only about one busy process. You may also need to understand load average, kernel time, disk wait, steal time from the host, and whether one core is saturated while the others are idle. This tutorial gives you a practical command sequence first, then explains how to interpret the numbers.

Key takeaways

• Use top for the quickest live view of server CPU usage and busy processes.
• Use htop when you want a more readable interactive process list.
• Use mpstat 1 5 for sampled CPU statistics over time instead of one instant.
• Watch %idle, %iowait, and %steal before blaming application code.
• Compare CPU usage with recent deploys, cron jobs, backups, traffic spikes, and monitoring alerts.
• For related operational habits, read the Virtarix guides to Linux command line tips, systemctl basics, VPS security checks, and securing a VPS.

Choose the right CPU command

Tool	Best for	What to look at first
top	Fast built-in live view	Load average, %Cpu(s), and %CPU per process
htop	Easier interactive investigation	Per-core bars, sort order, process tree, command names
mpstat	Measured CPU samples	%idle, %iowait, %steal, and per-CPU imbalance

If you only have thirty seconds, run top. If you are actively investigating a running box, use htop. If you need evidence for a ticket or a recurring incident, collect mpstat samples.

Step 1: Check CPU usage with top

Run:

top

The first few lines show the current time, uptime, load average, task counts, CPU state percentages, memory, and then a process table. In the process table, sort by CPU usage if it is not already sorted that way. In many top builds, pressing P sorts by CPU.

Focus on three areas:

1. The load average line.
2. The %Cpu(s) summary line.
3. The process table’s %CPU column.

A high %CPU process can be normal during compilation, backups, image processing, analytics jobs, or a burst of web traffic. It becomes a problem when it is unexpected, persistent, or paired with errors, timeouts, or slow user-facing pages.

Read the CPU summary line

A typical top CPU summary includes user time, system time, nice time, idle time, iowait, hardware interrupt time, software interrupt time, and steal time. The exact labels can vary, but the operational meaning is consistent enough for troubleshooting.

• High user time usually means applications are doing CPU work.
• High system time means the kernel is doing more work.
• High idle time means CPU is available.
• High iowait means the CPU is waiting while storage requests finish.
• High steal time on a VPS can mean the virtual CPU is waiting because the underlying host is busy.

Do not treat one line as a full diagnosis. A single top snapshot is useful for triage, but a few repeated samples are better.

Step 2: Use htop for an easier live view

If htop is installed, run:

htop

If it is missing on Ubuntu, install it from the package repositories:

sudo apt update
sudo apt install htop

htop is useful because the CPU meters and process list are easier to scan. You can sort, search, filter, and inspect full command lines without constantly retyping commands. Press F6 to change the sort column, search with /, toggle tree view with t, and quit with q or F10.

Use htop when the question is, “Which process is using CPU right now?” Sort by CPU, look at the command column, and confirm whether the busy process is expected. For example, a web worker, database process, backup process, compiler, or log parser may be legitimate during a known maintenance window.

Be careful before killing a process from htop. A busy process may be processing customer traffic, rebuilding an index, or finishing a backup. If you need a separate process-control guide, use the Virtarix article on Linux command line tips as a companion reference and document the action before changing production state.

Step 3: Use mpstat for measured CPU samples

Install sysstat if mpstat is not available:

sudo apt update
sudo apt install sysstat

Then take five one-second samples:

mpstat 1 5

This is better than one instant because it shows whether CPU pressure is sustained. For per-core output, run:

mpstat -P ALL 1 5

Per-core data matters when one single-threaded process saturates one CPU while the server still looks partly idle overall. It also helps separate an application bottleneck from a system-wide CPU shortage.

For a simple rule, look at the Average: line after the command completes. If %idle is consistently low, the server is busy. If %iowait is high, investigate disk or network-backed storage. If %steal is high on a VPS, record the samples and compare them with provider metrics or support guidance.

Step 4: Interpret load average with CPU usage

Load average is not a CPU percentage. It is a queue-style signal that becomes meaningful only when compared with the number of available CPU cores and the type of work running.

On an eight-core VPS, a load average of 4 may be fine. On a one-core VPS, a load average of 4 usually means work is waiting. Pair load average with top or mpstat output before deciding what to do.

Use this quick interpretation:

• High load and low idle CPU: CPU is likely the constraint.
• High load and high iowait: storage may be the constraint.
• High load and high steal: the virtualized host layer may be affecting the VPS.
• High load with one busy process: inspect that process, its logs, and its recent schedule.
• Low load with a short spike: keep watching before making changes.

Step 5: Decide what to do next

After you check CPU usage, do not immediately upgrade the server. First identify the pattern.

1. Confirm whether the spike is still happening.
2. Identify the busiest process or service.
3. Check whether the timing matches a deploy, cron job, backup, bot crawl, or traffic event.
4. Review service logs for errors or repeated retries.
5. Compare current CPU, memory, disk, and network signals.
6. If the problem is recurring, save command output with timestamps.

For short spikes, observation may be enough. For sustained high CPU, decide whether to optimize the workload, adjust worker counts, move scheduled jobs, add caching, or resize the VPS.

VPS examples

A web server is slow

Run top first. If PHP, Node.js, Python, or database workers dominate %CPU, compare the process list with access logs. A bot crawl, uncached endpoint, expensive query, or background queue can all create the same symptom.

CPU looks idle but the site is still slow

Run mpstat 1 5 and check iowait. If %iowait is high, the delay may be storage-related rather than CPU-bound. Also check memory pressure because swapping can make a server feel CPU-bound even when the CPU is not the root cause.

One core is maxed out

Run mpstat -P ALL 1 5. If one CPU is saturated and others are idle, look for a single-threaded process. Scaling vertically may help, but application-level changes or process concurrency may matter more.

Steal time is high

On virtual infrastructure, %steal can show time the virtual CPU wanted to run but the hypervisor was busy elsewhere. Save the mpstat output, note the time window, and compare it with provider status or support data before changing application code.

Common mistakes

Looking only at one screenshot

A single snapshot can catch the wrong moment. Use repeated samples when the incident lasts more than a few seconds.

Treating load average as CPU percent

Load average needs context. Always compare it with CPU count and the CPU state line.

Ignoring iowait

If the CPU is waiting on disk, adding more CPU may not fix the issue. Investigate storage, database queries, swap, or backup jobs.

Killing the busiest process too quickly

Stopping a process can interrupt customer requests or corrupt a maintenance operation. Identify the process, confirm ownership, and prefer graceful service controls when possible.

CPU usage checklist for VPS admins

Before you escalate or resize, capture:

1. top output showing the busiest processes.
2. mpstat 1 5 output showing sustained CPU state.
3. mpstat -P ALL 1 5 if per-core imbalance is possible.
4. The time the issue started.
5. Recent deploys, cron jobs, backups, and traffic changes.
6. Relevant application or system logs.

This gives you evidence instead of guesswork. It also helps another administrator reproduce your conclusion.

If you want a clean server for practicing Linux check CPU usage workflows, Virtarix Cloud VPS plans give you an isolated place to test top, htop, mpstat, logging, and monitoring habits before applying them to production workloads.

FAQ

What is the fastest way to check CPU usage on Linux?

Run top. It is the quickest live view on most Linux servers and shows CPU state plus per-process usage.

Is htop better than top?

htop is often easier to read and use interactively, but top is more likely to be available by default. Use whichever is present during an incident.

What does mpstat show that top does not?

mpstat is better for sampled processor statistics, especially per-core output and repeated interval measurements.

What does high steal time mean on a VPS?

High steal time means the virtual CPU is waiting while the hypervisor services other work. Record the timing and compare it with provider metrics or support advice.

Summary

A practical Linux check CPU usage workflow starts with top, moves to htop for interactive process investigation, and uses mpstat for sampled evidence. Do not stop at a single percentage. Read idle time, iowait, steal time, load average, and the process table together.

For VPS operations, the goal is not only to see that CPU is high. The goal is to decide whether the cause is application work, kernel work, storage wait, virtualization pressure, or a scheduled task. Once you know that pattern, you can optimize, reschedule, investigate logs, or resize with much more confidence.

Byline: Peter French — Updated 2026-05-18.