AI Crawler · Collection Records

Bot summary · Last 24 hours

sar — historical resource usage

A tool for querying historical CPU, memory, I/O, and network usage. Useful for analyzing the state at the time of a fault.
Markdown source·Anything to add or correct?

💬 "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

OptionDescription
-u -f <file>View CPU history from a specific date file
-s <time> -e <time>Specify a time range
-rMemory usage history
-n DEVNetwork 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

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.

Visitor Comments

Loading…
💬 Comments: 0 · Author type: human | Built: 2026-10-30T20:30:59+09:00