sar默认不保存历史数据，因其本身仅为实时快照工具，历史能力依赖sysstat的sa1/sa2后台服务；未启用该服务时，仅能查看当前或最近几分钟数据，且需手动开启ENABLED="true"、配置cron任务、确保日志目录存在并保留7天。
为什么 sar 默认不保存历史数据？
sar 本身只是读取 /proc 或内核接口的实时快照工具，它不自动记录——历史能力来自 sysstat 包附带的后台收集服务 sa1/sa2。没启用这个服务，sar -u 或 sar -r 只能查当前或最近几分钟（依赖 /var/log/sysstat/saXX 文件是否存在且未被轮转）。
常见错误现象：sar -u -f /var/log/sysstat/sa15 报错 “Cannot open /var/log/sysstat/sa15: No such file or directory”，本质是没人生成它。
- 确认
sysstat已安装并启用服务：systemctl is-enabled sysstat应返回enabled；若为disabled，需运行sudo systemctl enable --now sysstat - 服务实际由
/etc/cron.d/sysstat驱动，每 10 分钟调用一次sa1写二进制日志到/var/log/sysstat/saDD（DD 是日期，如 sa12 表示 12 日） - 默认只保留 7 天日志，超期自动清理；如需延长，修改
/etc/sysconfig/sysstat中的HISTORY=28
如何查某天的 CPU/内存/IO 负载峰值时间点？
事故定位核心是：先缩小日期范围，再按分钟级精度查具体时刻。不要用 sar -u 直接扫全量，效率低且难聚焦。
- 查某日整体趋势：用
sar -u -f /var/log/sysstat/sa15（15 日），输出含每 10 分钟一条的 %user/%system/%iowait；若看到某条 %iowait 突升到 90%，就记下那行的时间（如14:50:01） - 精确定位到分钟内：同一文件支持秒级采样，但需原始数据里有——确认
sa1是否配置了秒级采集（默认无）。如有，可用sar -u -s 14:45:00 -e 15:00:00 -f /var/log/sysstat/sa15截取窗口 - 跨指标关联：CPU 尖刺常伴随 IO 等待，同时跑
sar -b -f /var/log/sysstat/sa15（块设备统计）和sar -r -f /var/log/sysstat/sa15（内存页交换），比对时间戳是否重合
sar 输出里哪些字段最该盯住？
不是所有列都对故障有用。重点关注与资源争抢强相关的几个：
-
%iowait> 20% 持续 1 分钟以上，基本可断定磁盘或存储层瓶颈；注意：它不表示磁盘忙，而是 CPU 在等 IO 完成——可能是慢盘、RAID 降级、远端 NFS 卡顿 -
%idle长期 %system 显著高于%user，大概率是内核态开销异常（如中断风暴、驱动 bug） -
pgpgin/pgpgout（每秒换入/换出页数）突增 +%memused接近 100%，说明内存压力触发频繁 swap，此时sar -W的pswpin/pswpout也会飙升 - 网络类看
sar -n DEV的rxpck/s和txpck/s，但单看包数易误判；真正关键的是rxerr/s、txerr/s和coll/s（冲突），它们一高，八成是网卡或交换机问题
为什么用 sar 查不到刚发生的事故？
因为 sa1 默认每 10 分钟执行一次，最后一条记录可能比当前时间晚最多 10 分钟。刚崩的服务，其峰值大概率落在最近一个 sa1 周期之前，而那个周期的数据还没写入磁盘。
- 临时补救：立刻手动触发一次采集：
sudo sa1 $(date +%H%M) 1 1（立即采 1 次，间隔 1 秒），生成当前时间的临时文件，再用sar -u -f /var/log/sysstat/sa$(date +%d)查 - 长期改进：编辑
/etc/cron.d/sysstat，把*/10 * * * * root /usr/lib64/sa/sa1 1 1改成*/2 * * * * root /usr/lib64/sa/sa1 1 1（2 分钟粒度），代价是磁盘多占约 15% 空间 - 注意：高频采集不解决“事故瞬间”问题——
sar是采样，不是连续捕获。真要毫秒级定位，得上perf或bpftrace
真正的难点不在命令怎么敲，而在理解 sar 数据是离散快照，不是录像。时间点对不上时，优先怀疑采集间隔和系统时钟同步问题，而不是数据丢了。
