sar历史采集需手动启用sysstat服务并确保cron任务运行，检查enabled="true"、/etc/cron.d/sysstat存在且/var/log/sysstat/下有对应sadd文件；-f读取须用绝对路径且日期匹配，如sa28而非sa028；实时与历史模式参数逻辑不同，%iowait和%idle需结合上下文分析。
sar 默认不自动采集历史数据，必须手动启用 sysstat 服务并确认 cron 任务已运行，否则 sar -f 读取时会报 “No such file or directory” 错误。
如何确认 sar 历史采集已真正生效
很多人改完 /etc/default/sysstat 或 /etc/sysconfig/sysstat 就以为完事了，但实际没生效。关键要看三件事：
- 检查
ENABLED="true"是否已保存且未被注释（如#ENABLED="false"还在起作用） - 确认 cron 任务存在且可执行：
ls -l /etc/cron.d/sysstat，内容应包含类似*/10 * * * * root /usr/lib/sa/sa1 1 1的行 - 查看
/var/log/sysstat/目录下是否有最新日期的saXX文件（比如今天是 02 号，就该有sa02；若没有，说明至少还没过第一个 10 分钟采集周期）
常见错误现象：sar -u -f /var/log/sysstat/sa02 报错 Cannot open /var/log/sysstat/sa02: No such file or directory —— 不是命令写错，而是压根还没生成数据文件。
sar -f 读取历史数据时路径和日期必须严格匹配
sar -f 后面跟的必须是完整、可读的二进制数据文件路径，不能靠猜或补全。系统默认把每天数据存为 /var/log/sysstat/saDD（DD 是两位日期），但部分发行版（如较新 Ubuntu）可能用 /var/log/sa/ 路径，注意别进错目录。
- 先用
ls -lt /var/log/sysstat/或ls -lt /var/log/sa/确认真实路径和文件名 - 日期不是“今天”，而是数据采集当天：比如想查 3 月 28 日的数据，就得找
sa28，不是sa03或sa20260328 - 时间范围过滤要配合
-s和-e：例如sar -u -f /var/log/sysstat/sa28 -s 09:00:00 -e 11:30:00
容易踩的坑：sar -r -f sa28 失败——因为没写绝对路径；sar -u -f /var/log/sysstat/sa028 失败——多写了前导零，应为 sa28。
sar 实时采样与历史回溯的参数逻辑完全不同
新手常混淆两种用法：sar -u 1 5（实时：每秒一次，共 5 次） vs sar -u -f sa28（回溯：从已有文件读）。它们参数位置、含义、依赖条件都不同。
- 实时模式：最后两个数字是
间隔和次数，如sar -b 2 10表示每 2 秒采一次，共 10 次；省略次数则持续输出直到 Ctrl+C - 历史模式：不接受间隔/次数，只认
-f+ 文件路径；加-s/-e才能切时间段 -
-o是手动保存实时数据到指定文件（如sar -u -o /tmp/cpu.log 5 12），之后再用-f /tmp/cpu.log读，这和系统自动存的saXX是两套机制
性能影响提示：实时采样频率越高（如 1 100），对 CPU 和 I/O 的扰动越明显；而历史数据读取（-f）完全无开销，适合在生产机上随时查。
看懂 %iowait 和 %idle 才算真正会用 sar
这两个指标常被误读。%iowait 高 ≠ 磁盘慢，%idle 低 ≠ CPU 忙——得结合上下文判断。
-
%iowait是 CPU 空闲且在等 I/O 的时间占比。如果同时%idle很高（比如 >80%），说明 CPU 大量空转等磁盘，大概率是磁盘响应慢或队列积压；但如果%idle接近 0%，而%iowait也低，说明 CPU 根本没空等，瓶颈不在 I/O -
%idle长期 ≈ 0% 时，别急着扩容 CPU，先看sar -q的runq-sz（运行队列长度）是否持续 > CPU 核数，以及sar -w的cs（上下文切换）是否异常飙升 - 虚拟化环境（如 KVM、AWS EC2）中，
%iowait可能被宿主机调度掩盖，此时更应关注sar -d的await（I/O 平均等待毫秒）和%util（设备忙时百分比）
最容易被忽略的一点：sar 输出里的 Average: 行是全部采样点的算术平均，不能代表峰值压力。真要定位瞬时毛刺，得用高频率实时采样（如 sar -u 0.5 60）或搭配其他工具（如 perf）交叉验证。
