How to Monitor System Resources with htop, top and vmstat on RHEL 7

Effective system monitoring is the foundation of proactive administration. Whether you are troubleshooting a performance complaint, capacity planning for a growing workload, or simply verifying that a server is running within normal parameters, having command-line resource monitoring tools at your fingertips is essential. RHEL 7 ships with several powerful monitoring utilities: top is available by default, while htop, vmstat, iostat, and sar round out a comprehensive monitoring toolkit. This tutorial covers installing and using all of these tools, interpreting their output, and building habits that help you spot problems before they become outages.

Prerequisites

  • RHEL 7 system with root or sudo access
  • An active RHEL subscription or configured yum repository (EPEL required for htop)
  • Basic familiarity with the Linux command line

Step 1: Install htop from EPEL

Unlike top, which ships with the RHEL 7 base system as part of the procps-ng package, htop is not included in the Red Hat base repositories. It is available from the Extra Packages for Enterprise Linux (EPEL) repository.

First, enable EPEL on your RHEL 7 system:

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

Alternatively, if you have the EPEL repository configured in your organization’s satellite or local mirror:

sudo yum install epel-release -y

Now install htop:

sudo yum install htop -y

Also install the sysstat package, which provides iostat, sar, mpstat, and pidstat:

sudo yum install sysstat -y

Enable the sysstat service so that sar data is collected automatically:

sudo systemctl enable sysstat
sudo systemctl start sysstat

Step 2: Using htop — Interface and Navigation

Launch htop by simply typing:

htop

The interface is divided into three main sections:

Header (top panel)

The header displays per-CPU core usage bars, memory and swap usage bars, and key system statistics on the right:

  CPU[|||||||||||||||||||||||||         25.3%]   Tasks: 89, 15 thr; 1 running
  CPU[|||||||                           12.1%]   Load average: 0.45 0.38 0.31
  Mem[||||||||||||||||||||||||||||  2.34G/3.70G]
  Swp[                                0K/2.00G]
  • Each CPU bar shows utilization as a proportion of core capacity. Different colors indicate: blue = low-priority, green = normal, red = kernel processes
  • Load average: Three values showing 1-minute, 5-minute, and 15-minute averages. On a 4-core system, a load of 4.0 means fully utilized; above 4.0 means a queue is forming
  • Memory bar shows used/total. Different colors: green = used, blue = buffers, yellow = cache

Process list (main panel)

Each row is a process or thread. Key columns:

  • PID: Process ID
  • USER: Process owner
  • PRI/NI: Priority and nice value
  • VIRT: Virtual memory used (total address space)
  • RES: Resident memory (physical RAM actually in use — this is the number to watch)
  • SHR: Shared memory
  • CPU%: CPU usage percentage
  • MEM%: Memory percentage of total RAM
  • TIME+: Total CPU time consumed
  • Command: Process name or command line

Interactive keyboard shortcuts in htop

  • F1: Help
  • F2: Setup (customize columns, colors, meters)
  • F3 or /: Search for a process by name
  • F4: Filter processes
  • F5: Toggle tree view (shows parent/child process relationships)
  • F6: Sort by column
  • F9: Send a signal to selected process (kill, SIGTERM, SIGKILL, etc.)
  • F10 or q: Quit
  • u: Filter by user
  • k: Kill selected process
  • Space: Tag/untag a process (for bulk operations)
  • H: Toggle display of user threads
  • K: Toggle display of kernel threads

To run htop as root to see all processes and have permission to kill any process:

sudo htop

Step 3: Using top — The Built-in Process Monitor

top is available on every RHEL 7 system without additional packages. Launch it:

top

The summary area at the top shows:

top - 10:05:30 up 2 days,  3:22,  2 users,  load average: 0.45, 0.38, 0.31
Tasks: 89 total,   1 running,  88 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.2 us,  1.1 sy,  0.0 ni, 95.4 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :  3884620 total,   842340 free,  1234560 used,  1807720 buff/cache
KiB Swap:  2097148 total,  2097148 free,        0 used.  2356780 avail Mem

Understanding the CPU line (%Cpu(s)):

  • us: User space CPU (your applications)
  • sy: Kernel/system CPU
  • ni: Nice (low-priority processes)
  • id: Idle — the higher this is, the more headroom you have
  • wa: I/O wait — if this is consistently above 5–10%, disk I/O is a bottleneck
  • hi: Hardware interrupt handling
  • si: Software interrupt handling
  • st: Steal time (on VMs — CPU stolen by the hypervisor; concerning if consistently non-zero)

Interactive keys in top

  • P: Sort by CPU usage (default)
  • M: Sort by memory usage (RES column)
  • T: Sort by cumulative CPU time
  • 1: Toggle between aggregate CPU and per-core CPU display
  • k: Kill a process (prompts for PID and signal)
  • r: Renice a process
  • c: Toggle between command name and full command line
  • d or s: Change refresh interval (seconds)
  • f: Select fields to display
  • u: Filter by user
  • q: Quit

Run top in batch mode for scripting (outputs to stdout):

top -bn1 | head -20

Step 4: Using vmstat for Memory, CPU and I/O Overview

vmstat provides a quick snapshot or continuous stream of virtual memory statistics. It is particularly useful for identifying memory pressure, swap activity, and CPU I/O wait.

Get a single snapshot:

vmstat

Run continuously every 2 seconds, 10 times:

vmstat 2 10

Example output:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 842340  45120 1762600    0    0     5    10  120  340  3  1 95  1  0
 0  0      0 842100  45120 1762800    0    0     0    12  110  310  2  1 97  0  0

Key columns:

  • r: Processes waiting for CPU (run queue). Consistently above CPU count indicates CPU saturation
  • b: Processes in uninterruptible sleep (waiting for I/O)
  • swpd: Amount of swap used (KB)
  • si: Swap-in rate (KB/s) — pages read from swap into RAM
  • so: Swap-out rate (KB/s) — pages written from RAM to swap. Non-zero values indicate memory pressure
  • bi: Block input (KB/s) — disk reads
  • bo: Block output (KB/s) — disk writes
  • wa: I/O wait percentage

Show memory statistics in megabytes:

vmstat -S M 2 5

Step 5: Using iostat for Disk I/O Analysis

iostat (from the sysstat package) provides detailed disk I/O statistics per device:

iostat -xh 2 5

The -x flag shows extended statistics, -h makes output human-readable. Example output:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     1.50    0.50    5.20     0.02     0.08    28.00     0.02    3.50    2.10    3.60   1.50   0.90

Key metrics to watch:

  • %util: Disk utilization percentage. Consistently near 100% indicates a disk I/O bottleneck
  • await: Average time (ms) for I/O requests to complete. Above 10–20ms on a spinning disk or above 1–2ms on SSDs warrants investigation
  • avgqu-sz: Average I/O queue length. Values above 1.0 indicate the disk is not keeping up

Step 6: Using sar for Historical Performance Analysis

sar (System Activity Reporter) is the most powerful tool in the sysstat package because it records historical data. The sysstat service collects data every 10 minutes by default, stored in /var/log/sa/.

View today’s CPU statistics in 30-minute intervals:

sar -u 1800 -f /var/log/sa/sa$(date +%d)

View memory usage history for today:

sar -r -f /var/log/sa/sa$(date +%d)

View disk I/O history:

sar -b -f /var/log/sa/sa$(date +%d)

View network statistics:

sar -n DEV -f /var/log/sa/sa$(date +%d)

Collect live sar data every 2 seconds for 5 samples:

sar -u 2 5

Historical data is invaluable when users report “the server was slow this morning” — you can look back at the sar archives and see exactly what CPU, memory, I/O, and swap were doing at that time, which is impossible with real-time tools alone.

Step 7: Interpreting and Acting on Metrics

Understanding what you are seeing is as important as knowing how to collect the data. Here is a quick reference for common performance patterns:

High CPU usage (us%)

One or more applications are consuming excessive CPU. Use htop or top sorted by CPU to identify the culprit process. Check if it is expected behavior (batch job, compilation) or a runaway process.

High I/O wait (wa%)

Processes are frequently waiting for disk I/O. Use iostat -x to identify which disk is saturated. Consider faster storage, adding read caching, or optimizing the application’s I/O patterns.

Swap activity (si/so non-zero)

The system is under memory pressure. Identify the memory-hungry process with htop sorted by RES. Either add RAM, reduce the workload, or tune the application’s memory settings.

High load average relative to CPU count

A load average consistently higher than the number of CPU cores means processes are waiting for CPU time. Identify if the wait is CPU-bound (r column in vmstat is high) or I/O-bound (b column and wa% are high).

Steal time non-zero (st%)

On a virtual machine, non-zero steal time means the hypervisor is giving CPU cycles to other VMs instead of yours. This indicates the physical host is overcommitted. Contact your infrastructure team or migrate to a less loaded host.

Building a monitoring practice on RHEL 7 with htop, top, vmstat, iostat, and sar gives you both real-time visibility and historical trending in a completely free, no-agent toolchain. Start by familiarizing yourself with the normal baseline behavior of your servers using sar archives, then use the interactive tools during incidents to quickly isolate whether the issue is CPU, memory, or disk I/O — and in which specific process or device. This systematic approach transforms reactive firefighting into methodical diagnosis.