每天学一个Linux命令系列(进阶篇22):sar - 昨天CPU飙高我没看到?sar翻历史记录

场景引入：错过了高峰的"犯罪现场"

凌晨三点，你的手机突然收到报警：CPU使用率持续100%！但你当时在睡觉。早上到公司，服务器已经恢复正常了。你问同事昨晚发生了什么？没人知道。查系统日志？日志被轮转覆盖了。这时候你是不是很想有个"性能回放"功能，看看昨晚服务器到底经历了什么？

sar（System Activity Reporter，系统活动报告器）就是干这个的。它会长期、持续地采集系统各项指标，让你可以回溯任何时间段的性能数据。理解成"服务器的行车记录仪"就对了。

原理：sysstat是如何工作的

sar由sysstat包提供。它依赖三个组件协同工作：

sadc（System Activity Data Collector，系统活动数据采集器）是后台守护进程，定期采样系统数据。sa1是调用sadc的shell脚本，sa2是生成每日报告的脚本。

采集的数据默认存放在 /var/log/sysstat/ 目录下，文件名是 sa{日期}，比如 sa27 表示27号的数据。注意这些文件是二进制格式的，不能直接用cat看，必须通过sar命令读取。

在Ubuntu系统上，sysstat默认每10分钟采样一次。如果一分钟前服务器飙高过，数据已经存在那个时间点的采样里了，直接用sar读取即可。

安装和启动

不同系统的安装方式：

# 在Ubuntu/Debian上安装sysstat包
sudo apt-get install sysstat
# 在CentOS/RHEL上安装sysstat包
sudo yum install sysstat

安装完后需要启用数据采集。Ubuntu上默认是关闭的：

# 编辑sysstat配置文件，将ENABLED改为true启用数据采集
sudo vim /etc/default/sysstat
# 找到 ENABLED="false" 改为 ENABLED="true"

# 重启sysstat服务让配置生效
sudo systemctl restart sysstat
# 查看服务状态确认正常运行
sudo systemctl status sysstat

确认数据已经开始采集：

# 查看数据目录中是否已有当日的数据文件
ls -la /var/log/sysstat/

如果看到 sa27 这样的文件，说明采集已经正常运行了。

sar -u：查看CPU历史使用率

回溯CPU使用率是sar最常用的功能：

# 查看今天到目前为止的CPU使用率
sar -u
# 查看昨天的CPU使用率（指定数据文件为昨天的）
sar -u -f /var/log/sysstat/sa26

输出示例（模拟）：

Linux 5.4.0-100-generic (myserver)    2026-07-27    _x86_64_    (4 CPU)

09:00:01     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:10:01     all      5.20      0.00      3.10      0.50      0.00     91.20
09:20:01     all     65.30      0.00     22.50     12.00      0.00      0.20
09:30:01     all      4.80      0.00      2.90      0.40      0.00     91.90
09:40:01     all      5.10      0.00      3.00      0.60      0.00     91.30

注意09:20这个时间点，%user高达65%，%system也到了22.5%，iowait到了12%。这说明那十分钟内服务器压力巨大。和监控告警的时间点对比一下，大概率就是问题发生的时间窗口。

还能看平均CPU负载：

# 查看CPU平均负载（运行队列中的进程数）
sar -q

输出中的runq-sz（运行队列大小）如果持续大于CPU核数，说明CPU不够用了。

sar -r：查看内存使用

回溯内存使用同样方便：

# 查看今天的内存使用情况
sar -r
# 查看昨天指定时间范围的内存使用（08:00到12:00）
sar -r -s 08:00:00 -e 12:00:00

重点关注 kbmemused（已使用内存）、kbmemfree（空闲内存）、和最重要的 kbbuffers 和 kbcached（缓存和缓冲区使用的内存）。真正的"剩余内存"应该是 free + buff/cache 中可回收的部分。

我遇到过一个内存泄漏问题的排查。应用对外的表现是运行两天后变慢，重启后恢复正常。用sar查看内存趋势：

# 回溯查看几天内的内存使用趋势
sar -r -f /var/log/sysstat/sa25
sar -r -f /var/log/sysstat/sa26
sar -r

对比发现，sa25时kbmemused是2GB，sa26涨到4GB，到当天已经涨到7GB（总共8GB内存）。内存的持续增长曲线明确指向了内存泄漏。

sar -b：查看磁盘I/O

磁盘I/O的历史数据同样可以回溯：

# 查看今天的磁盘I/O统计
sar -b
# 查看昨天的磁盘I/O统计
sar -b -f /var/log/sysstat/sa26

输出中的 tps（每秒传输次数）、rtps（每秒读请求数）、wtps（每秒写请求数）、bread/s（每秒读取的数据块数）、bwrtn/s（每秒写入的数据块数）可以反映磁盘I/O负载。

如果需要看每个磁盘的详细情况：

# 查看每个磁盘的详细I/O统计，包括await和%util
sar -d -p

-p 参数显示友好的磁盘名称（比如sda而不是dev8-0）。输出中的 await（平均I/O等待时间，单位毫秒）和 %util（磁盘利用率）是判断磁盘是否成为瓶颈的关键指标。这两个指标在前面iostat文章里详细介绍过，在sar里的含义是一样的。

sar -n DEV：查看网络流量

网络流量异常也是定位问题的常用手段：

# 查看今天各网络接口的历史流量
sar -n DEV

输出包括 rxkB/s（每秒接收字节数）、txkB/s（每秒发送字节数）、rxcmp/s（每秒接收压缩包数）、txcmp/s（每秒发送压缩包数）。可以用来回溯突发的网络流量高峰。

有一次我帮客户排查，他们服务器带宽费用异常高。用sar回溯了最近一周的网络流量：

# 回溯查看一周内eth0接口的流量
sar -n DEV -f /var/log/sysstat/sa20
sar -n DEV -f /var/log/sysstat/sa21
# ...连续查看几天数据，发现某个时间段txkB/s异常高

发现每天凌晨2点到4点，txkB/s是其他时段的10倍。顺着时间点排查，是一台备份服务器在那个时段全量同步数据，占满了带宽。

sar -S：查看交换空间

交换空间的频繁使用是内存不足的明确信号：

# 查看交换空间使用历史
sar -S

swapin/s（每秒交换入的页面数）和 swapout/s（每秒交换出的页面数）如果持续大于0，说明物理内存已经不够用了，系统不得不把内存页面换到磁盘上。这是一个严重的性能问题，因为磁盘比内存慢好几个数量级。

指定时间范围：-s和-e

默认情况下，sar显示当天0点到当前的数据。如果你想看特定时间段，用 -s（开始时间）和 -e（结束时间）：

# 查看今天下午2点到4点之间的CPU使用数据
sar -u -s 14:00:00 -e 16:00:00
# 查看昨天某个具体时间段的磁盘I/O
sar -b -f /var/log/sysstat/sa26 -s 08:30:00 -e 09:30:00

还可以指定采样间隔和次数：

# 实时模式：每2秒采样一次，共5次（类似vmstat/iostat的实时监控）
sar -u 2 5

这个功能在排查实时问题时很有用，不用同时在终端开多个工具。

日志保留策略

默认情况下，sysstat在Ubuntu上保留7天的数据。数据保留策略由 /etc/sysstat/sysstat 中的 HISTORY 参数控制：

# 查看当前sysstat配置
grep HISTORY /etc/sysstat/sysstat
# 修改保留天数为30天（注意：保留天数增多会占用更多磁盘空间）
sudo sed -i 's/HISTORY=7/HISTORY=30/' /etc/sysstat/sysstat

数据文件的位置和轮转由cron管理：

# 查看sysstat的cron配置
cat /etc/cron.d/sysstat

默认配置下，每10分钟采集一次，每天凌晨的系统任务会把前一天的二进制数据归档。sa文件是二进制的，所以最好不要手动删除某个文件，而是通过修改HISTORY值让系统自动管理。

我自己的习惯是把HISTORY改成30天。对于生产环境服务器，7天的历史数据往往不够用。比如周一才发现上周五出过一次问题，如果日志只保留7天可能已经被覆盖了。

安全提醒

使用sar和sysstat时要注意几个事项。第一，sa文件会占用磁盘空间。默认7天大概占用几十到几百MB，如果把HISTORY改大，要确认磁盘空间够用。第二，千万不要手动编辑或删除 /var/log/sysstat/ 下的sa文件，它们是二进制格式，如果编辑损坏了可能导致sar读取报错。第三，在一些高安全级别的环境中，sysstat采集的数据可能包含敏感信息（比如具体进程名、连接IP等），如果日志文件被其他人读取可能导致信息泄露。建议设置合适的文件权限。第四，使用 sar -f 选项读取历史数据时，确保当前系统时间和数据文件的时间一致，否则显示的时间可能有偏差。我曾经遇到一台服务器时区设置错误，读出来的数据时间全错位了，排查了半天才发现是时区问题。

小结

sar最大的价值在于它的"历史回溯"能力。其他监控工具（top、iostat、vmstat）看的是"现在"，sar看的是"过去"。当你错过了故障现场，sar就是你还原现场的唯一手段。常用参数组合记住：sar -u 看CPU、sar -r 看内存、sar -b 看磁盘、sar -n DEV 看网络、sar -S 看交换空间。配合 -f 指定历史数据文件、-s -e 指定时间范围，你基本可以还原任意时间点的服务器状态。