sar是sysstat包中的系统性能分析工具，可报告cpu、内存、i/o、网络等多维度活动；需安装sysstat并启用历史采集（如配置enabled="true"及cron任务）才能回溯分析，否则仅支持实时采样。

sar 不是独立安装的工具，它属于 sysstat 包。没装 sysstat，sar 就不存在；装了但没启用采集，sar 只能看实时数据，无法回溯历史。

---

确认 sysstat 是否已安装并启用历史采集

很多发行版预装了 sysstat，但默认禁用历史数据收集。必须手动开启，否则 sar -f /var/log/sysstat/saXX 会报错 No such file or directory。

• 检查是否安装：which sar 或 dpkg -l sysstat（Debian/Ubuntu）、rpm -q sysstat（RHEL/CentOS）
• 检查是否启用采集：
  • Debian/Ubuntu：查看 /etc/default/sysstat，确认 ENABLED="true"
  • RHEL/CentOS：查看 /etc/sysconfig/sysstat，确认 ENABLED="true"
• 检查 cron 是否生效：ls /etc/cron.d/sysstat 应存在，且内容包含类似 <em>/10 </em> <em> </em> * root /usr/lib64/sa/sa1 -F -L 的行
• 首次启用后，需等待至少一个采集周期（默认 10 分钟）才会生成首个 /var/log/sysstat/saXX 文件（XX 是当天日期，如 sa19）

---

sar -f 查历史数据时常见路径和日期错误

sar -f 后面跟的必须是完整、存在的二进制数据文件路径，不是目录，也不是任意日期名。

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• 正确路径格式：sar -u -f /var/log/sysstat/sa19（查今天）
• 错误写法示例：
  • sar -u -f /var/log/sysstat/ → 缺少具体文件名
  • sar -u -f /var/log/sysstat/sa25 → 25 号还没到，文件不存在
  • sar -u -f /var/log/sysstat/sa05 → 5 号文件存在，但你当前是 5 月 19 日，sa05 实际对应 本月 5 日（不是上月），别搞混月份
• 查看可用历史文件：ls -t /var/log/sysstat/sa[0-9][0-9]（只列 sa 开头的两位数日期文件）
• 注意：saXX 文件是二进制格式，不能用 cat 直接读；必须用 sar -f 解析

---

按指标类型选对 sar 参数和时间范围

不同子系统用不同选项，参数错一个，输出就完全不对，而且不会报错——容易误判。

• CPU 使用率：sar -u -f /var/log/sysstat/sa19（含 %user、%system、%iowait、%idle）
• 内存使用：sar -r -f /var/log/sysstat/sa19（看 %memused、kbmemfree、kbbuffers）
• 磁盘 I/O 总体吞吐：sar -b -f /var/log/sysstat/sa19（tps、rd_sec/s、wr_sec/s）
• 单个磁盘详细延迟与队列：sar -d -p -f /var/log/sysstat/sa19（-p 让设备名可读，如 sda 而非数字编号）
• 网卡流量：sar -n DEV -f /var/log/sysstat/sa19（显示 eth0、ens33 等接口的 rxkB/s、txkB/s）
• 加时间范围（精确到秒）：sar -u -f /var/log/sysstat/sa19 14:00:00 15:30:00

---

为什么 %iowait 高不一定代表磁盘慢？

sar -u 输出里的 %iowait 是 CPU 等待 I/O 完成的时间占比，但它受虚拟化层、存储栈、队列深度等影响，不能直接等同于磁盘响应慢。

• 在 KVM/QEMU 或云主机中，%iowait 可能被虚机监控层“放大”，而实际块设备延迟（await）在 sar -d 中才体现
• NVMe 设备下，%iowait 常偏低，但队列堆积（avgqu-sz）或高 %util 才是瓶颈信号
• 真正要看磁盘是否拖慢系统，得组合看：
  • sar -d -p -f /var/log/sysstat/sa19 中的 await（平均 I/O 延迟，单位 ms）
  • svctm（服务时间，已废弃，忽略）
  • %util（设备忙时百分比，接近 100% 表示饱和）

历史数据的价值不在单点数值，而在趋势对比——比如某天凌晨 %iowait 从 2% 突升至 35%，再结合 sar -d 发现同期 await 从 0.3ms 涨到 12ms，这才构成有效线索。