Monitor Linux CPU, Memory, Disk, and Process Activity

When a Linux host feels slow, a single snapshot rarely explains why. A short, repeatable sample of CPU, memory, storage, and process activity can show whether a workload is CPU-bound, waiting on disk, or under memory pressure.

This tutorial uses the sysstat tools: iostat for device activity and pidstat for per-process resource use. The examples collect observations only. Package names and availability vary by distribution, and these samples are diagnostic snapshots rather than long-term monitoring or alerting.

---

Step 1: Install the Monitoring Tools

01

Install sysstat and Confirm the Commands

Setup

Install the distribution’s sysstat package if iostat or pidstat is missing. These examples cover Debian/Ubuntu and Fedora/RHEL family package managers; use your distribution’s approved repository and change process.

# Debian or Ubuntu
sudo apt update
sudo apt install sysstat

# Fedora, RHEL, or compatible distributions
sudo dnf install sysstat

command -v iostat pidstat

❯ View Expected Console Output

/usr/bin/iostat
/usr/bin/pidstat

---

Step 2: Take a Quick CPU and Memory Sample

02

Sample Run Queue, CPU, and Memory

System Snapshot

Record host uptime and memory first, then take five one-second samples with vmstat. In its CPU columns, high id means idle time; consistently low idle time can point to CPU pressure. Nonzero wa can indicate time waiting on I/O, while sustained swap activity deserves closer investigation. Interpret the whole sample rather than one interval.

uptime
free -h
vmstat 1 5

❯ View Expected Console 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  ...    ...    ...      0    0     2     8  ...  ... 12  3 84  1  0

---

Step 3: Check Device Latency and Throughput

03

Review Per-Device I/O Statistics

Storage Activity

Run extended device statistics for five intervals. Compare devices over the same workload window. Queue depth, throughput, and await can help identify I/O pressure, but their meaning depends on device type and workload; high utilization alone does not prove a disk is the bottleneck.

iostat -xz 1 5

❯ View Expected Console Output

Device   r/s   w/s   rkB/s   wkB/s  await  aqu-sz  %util
nvme0n1  ...   ...   ...     ...    ...    ...     ...

---

Step 4: Find Processes Using CPU, Memory, or I/O

04

Attribute Resource Use to Processes

Process Detail

Sample per-process CPU, memory, and I/O counters during the same period as the system-wide checks. The -d option adds I/O statistics and -r adds memory statistics. Use sudo when you need visibility into processes owned by other users.

sudo pidstat -dur 1 5

❯ View Expected Console Output

Linux ...
# Time      UID  PID  %usr %system  %CPU  Command
...         ...  ...   ...    ...    ...  service-name

Figure 1: Live CPU, memory, disk, and per-process samples collected with vmstat, iostat, and pidstat.

---

Step 5: Compare Samples and Record a Baseline

05

Relate the Metrics to the Symptom

Analysis

Repeat the same commands while the issue is happening and during a healthy period. Note the time, workload, host name, and unusual values. Compare the pattern: busy CPU with a long run queue suggests compute contention; growing swap use can point to memory pressure; elevated I/O wait together with device latency suggests storage needs attention. Confirm findings against application metrics and logs before changing configuration.

hostname
uptime
free -h
vmstat 1 5
iostat -xz 1 5
sudo pidstat -dur 1 5

❯ View Expected Console Output

Keep timestamped samples from comparable workload windows so trends can be compared.

For the tools included in the package, see the sysstat project documentation and the iostat manual.