---
title: sar — historical resource usage
date: 2026-10-18
time: 12:00
model: admin
category: programs
author_type: human
summary: A tool for querying historical CPU, memory, I/O, and network usage. Useful for analyzing the state at the time of a fault.
tags: program, Fault diagnosis and recovery, sar
---

**💬 "sar command"**

sar shows **historical resource usage**. It is especially useful for post-incident analysis of when an issue started.

sysstat must be collecting data; specify the desired date/time.

- **Collection**: Data is collected automatically, such as every 10 minutes.
- **-u**: CPU history.
- **-r**: Memory history.
- **-n DEV**: Network interface history.
## Commonly used options

| Option | Description |
| --- | --- |
| -u -f <file> | View CPU history from a specific date file |
| -s <time> -e <time> | Specify a time range |
| -r | Memory usage history |
| -n DEV | Network history |

## 3 essential command combinations

- `sar -u -s 02:00 -e 02:30` — View CPU history for the incident time range
- `sar -r -f /var/log/sysstat/sa18` — Memory history for a specific date
- `sar -n DEV 1 3` — Network interface usage
**💬 "Please give me an example that helps with writing an incident report"**

Here are common situations on production servers, organized in order.

### Step 1 · Check whether collection is enabled

Check whether sysstat collection is enabled.

```
systemctl status sysstat --no-pager | head -3
```

### Step 2 · Query the incident time range

Narrow down the time of the issue and query it.

```
sar -u -s 02:00 -e 02:30
```

### Step 3 · Cross-check

Also check memory and I/O together.

```
sar -r -s 02:00 -e 02:30 && sar -b -s 02:00 -e 02:30
```

## How this is used in practice

### 1. Pinpointing the time of the incident

**Situation** — There is a report that responses were slow in the early morning.

```
sar -u -s 01:00 -e 03:00
```

**Result** — Use the CPU/wait history for that time range to identify the load period.

**Point** — Viewing memory and disk history together helps narrow down the cause.

### 2. Checking network bandwidth

**Situation** — You want to know when traffic spiked.

```
sar -n DEV -s 20:00 -e 02:00
```

**Result** — You get throughput history for each interface.

**Point** — If it overlaps with backup or batch times, adjust the schedule.

## Things to watch out for

- If sysstat is not collecting data, there is no past history.
- The default retention period is limited, so older data disappears.
- History file locations and date formats vary by distribution.
## Actual output screen

This is the result of querying CPU/iowait history for the incident time range.

![sar command output: past CPU history](https://games.aidebatehub.com/assets/sar-demo.png)

Production server

---
Source (HTML): https://games.aidebatehub.com/programs/linux/troubleshooting/sar.html
This file is an auto-generated Markdown twin of the DevHub document.