Diagnosing High CPU Usage on Linux with top and htop

Picture this: a Monday morning, your phone lights up with a PagerDuty alert that a production node is slow. The team scrambles to SSH in from Brisbane over the NBN, and the first instinct is to throw more resources at the problem. Before any scaling decision, however, you need to know what is actually consuming CPU cycles. Two utilities remain the fastest way to get that picture on RHEL, CentOS, Fedora, and their derivatives: the classic top command and its more visually friendly cousin, htop.

While top ships with virtually every Linux distribution and runs in non-interactive mode, htop adds colour, process tree views, and mouse support that can shave minutes off a frantic troubleshooting session. Both tools sample kernel data from /proc at roughly two-second intervals, but how they present that information differs in ways worth understanding before you start interpreting output.

For Australian administrators, latency to overseas-hosted infrastructure is often the hidden cost of doing business, especially when managing fleets in Singapore, Tokyo, or the US West Coast. Spending an extra minute with the right monitoring tool on a local box in Sydney or Melbourne is faster than waiting on a sluggish remote console.

Installing htop on RHEL, CentOS, and Fedora

top ships with every RPM-based distribution via the procps-ng package, which is part of every base install. htop comes from the EPEL repository on RHEL and CentOS, while Fedora includes it directly. On RHEL 9 and CentOS Stream, run sudo dnf install epel-release -y followed by sudo dnf install htop -y. Fedora users can install directly with sudo dnf install htop.

After installation, verify the binary with which htop and check the man page with man htop. The man page explains the difference between the two views available in non-interactive mode and the many sort options, including the common %CPU and TIME+ columns.

Reading the top and htop Interfaces

When you launch top with no flags, the top of the screen summarises system load. The first line shows uptime, logged-in users, and load average for the last one, five, and fifteen minutes. On an Australian server, remember AEST is UTC+10 (or UTC+11 with daylight saving in New South Wales, Victoria, Tasmania, and the ACT), so log file timestamps correlate with the local time of your engineers.

The CPU line shows the percentage breakdown: us is user space, sy is kernel, id is idle, wa is I/O wait, and st is steal time. Steal time is particularly relevant on cloud platforms like AWS Sydney or Azure Australia Central, where noisy neighbours inflate your apparent CPU usage without any fault of your own application.

htop presents the same data with a more digestible layout. Bar graphs at the top show per-core utilisation, memory, and swap usage at a glance. Mouse support means you can sort columns with a click, kill processes with F9, and renice with F8. Press F5 to toggle the tree view and isolate a runaway worker forked from nginx, php-fpm, or a custom Go service. In top, press 1 to expand the CPU line into per-core statistics and capital H to toggle thread view.

Identifying CPU-Hungry Processes

Once you have a baseline, sort by %CPU and look for processes consuming more than their fair share. A single request handler on a typical web server should rarely exceed 20% of a single core. If you see a process at 95% or higher, click into it. Press capital H in top to toggle thread view, essential when a multi-threaded application has a single hot thread.

Use ps -p PID -o pid,ppid,cmd or the more detailed pidstat -p PID 2 5 from the sysstat package to gather context. If the process is one you don't recognise, cross-reference its executable path against /proc/PID/exe. Advisories from the ACSC occasionally flag malicious binaries masquerading as system processes, so unfamiliar names warrant a closer look.

Common Causes and Quick Fixes

The usual suspects include runaway application workers (a stuck cron job, an infinite loop), database queries from analytical reports, and I/O-bound workloads (often a swap, or for storage-heavy ops a misconfigured RAID array). For deeper storage diagnostics, the walkthrough on creating a RAID 5 array with mdadm on CentOS covers the rebuilding process that often surfaces as high I/O wait.

After identifying the culprit, react with kill -15 PID for a graceful shutdown, or kill -9 PID only if the application refuses to stop. Renice with renice -n 19 -p PID to lower its priority if the process is legitimate but lower-priority. For a permanent fix, edit the systemd unit to add CPUQuota=200% or similar, or use cgroups with systemd-run for finer control.

Logging and Automation for Ongoing Monitoring

top in batch mode is useful for cron-driven logging. Run top -b -n 1 -k %CPU | head -30 every five minutes, redirect to a file, and rotate with logrotate. For teams juggling system administration and project deadlines, a practical project tracker helps coordinate incident reviews alongside scheduled maintenance windows.

Tools like sysstat's sar provide historical data: sar -u 2 5 shows CPU utilisation snapshots. Combine with Prometheus node_exporter and Grafana for longer-term dashboards, especially valuable when investigating whether performance issues correlate with AEST business hours or with AEDT summer-clock transitions across Australia's east coast.

When the Spikes Persist

If top and htop show nothing dramatic yet your workload remains impacted, the bottleneck may be elsewhere. Check memory pressure with free -h, CPU sampling with perf top, and storage diagnostics with iostat -xz 2. Network latency to upstream services can mimic CPU issues if your application is thread-saturated waiting on responses.

Finally, document every finding. Capture screenshots of htop before and after the fix, save the top output to a ticket, and share with the team. The next time that alert fires at 3 AM AEDT, the institutional memory will shorten the mean time to recovery.

Build the habit of running top or htop every morning before work. Thirty seconds of looking at the load average and top three processes becomes muscle memory. Above all else, these utilities ship with every Linux distribution, run over the slowest remote connections, and never require a licence.