Skip to main content

sar — System Activity Reporter (Historical Metrics)

sar reports system activity (CPU, memory, disk, network) either live or from historical sysstat logs. Use it when a WordPress incident happened in the past and you need evidence: CPU spikes, I/O saturation, memory pressure, or network issues during a specific window. It complements real-time tools like top and vmstat by letting you look backward.

Quick Summary

For live sampling: sar -u 1 3. For historical data: sar -u -f /var/log/sysstat/sa01 (file names vary by distro).

Mental Model

Prerequisites

sar is provided by the sysstat package, and historical reporting requires data collection to be enabled.

Install sysstat:

install-sysstat-apt.sh
sudo apt update
sudo apt install -y sysstat

Enable collection (distribution-specific):

note

If you only run sar live (sar -u 1 3), collection is not required. For historical charts, the collector must have been running before the incident.

Core Syntax

sar-syntax.sh
sar [options] [interval [count]]
sar [options] -f /path/to/sar-data-file

Common Reports

ReportWhat it showsExampleWordPress / VPS use case
CPUCPU utilizationsar -u 1 3CPU spikes during traffic
LoadLoad average / queuesar -q 1 3Confirm sustained saturation
MemoryMemory utilizationsar -r 1 3Memory pressure and cache behavior
SwapSwap activitysar -W 1 3Swapping during peak
DiskBlock devices I/Osar -d 1 3Disk bottlenecks
NetworkInterface statssar -n DEV 1 3Network throughput and errors

Examples (Commands + Expected Output)

Output varies

Field names and availability depend on kernel + sysstat version.

Live CPU sampling

sar-cpu-live.sh
sar -u 1 3

Expected output:

example-output-sar-u.txt
10:30:01 AM CPU %user %system %iowait %idle
10:30:02 AM all 8.00 2.00 1.00 89.00
10:30:03 AM all 40.00 10.00 5.00 45.00

Use case: Confirm whether CPU (or iowait) spikes align with slow requests.

Live load average / run queue

sar-load-live.sh
sar -q 1 3

Expected output:

example-output-sar-q.txt
10:30:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15
10:30:02 AM 2 150 0.50 0.40 0.30

Use case: Validate whether load is sustained.

Live memory utilization

sar-memory-live.sh
sar -r 1 3

Expected output:

example-output-sar-r.txt
10:30:01 AM kbmemfree kbmemused %memused kbbuffers kbcached
10:30:02 AM 120000 900000 88.00 60000 500000

Use case: Confirm memory pressure during peaks.

Live swap activity

sar-swap-live.sh
sar -W 1 3

Expected output:

example-output-sar-W.txt
10:30:01 AM pswpin/s pswpout/s
10:30:02 AM 0.00 0.00
10:30:03 AM 10.00 5.00

Use case: Swapping indicates memory pressure and can cause slow PHP response.

Live disk stats (per device)

sar-disk-live.sh
sar -d 1 3

Expected output:

example-output-sar-d.txt
10:30:01 AM DEV tps rd_sec/s wr_sec/s avgrq-sz await %util
10:30:02 AM sda 20.0 100.0 200.0 15.0 8.0 60.0

Use case: Detect disk saturation over time (confirm with iostat -xz).

Live network interface stats

sar-network-live.sh
sar -n DEV 1 3

Expected output:

example-output-sar-n-dev.txt
10:30:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s
10:30:02 AM eth0 50.00 45.00 120.0 110.0

Use case: Confirm throughput and traffic patterns.

Read historical CPU data from a file

sar-historical-file.sh
sar -u -f /var/log/sysstat/sa01

Expected output:

example-output-sar-file.txt
09:00:00 AM all 5.00 1.00 0.50 93.50
10:00:00 AM all 60.00 15.00 8.00 17.00

Use case: Identify when CPU pressure occurred.

WordPress VPS Use Cases

QuestionBest reportCommandWhy
Was the server CPU-bound during the outage?CPUsar -u -f ...Historical CPU utilization
Was disk I/O the bottleneck?Disksar -d -f ...Confirms %util/await over time
Did the server swap?Swapsar -W -f ...Swapping correlates with slow responses
Was there a traffic surge?Networksar -n DEV -f ...Throughput and packet rates

Troubleshooting

ProblemLikely causeFix
sar: command not foundsysstat not installedInstall sysstat
No historical filesCollector not enabled or logs rotatedUse live mode, and enable collection going forward
Permission errors reading /var/log/sysstatRestricted log directoryUse sudo to read historical logs

Best Practices

  • Use sar after the incident to validate whether the root cause was CPU, memory, disk, or network.
  • Combine with top and application logs for a full picture.
Cheat Sheet
sar-cheat-sheet.sh
sar -u 1 3
sar -q 1 3
sar -r 1 3
sar -W 1 3
sar -d 1 3
sar -n DEV 1 3
sar -u -f /var/log/sysstat/sa01

What's Next