为什么 sar 查不到昨天的 CPU 数据？
默认情况下，sar 不保存历史数据，只显示当前启动后收集的实时采样。你执行 sar -u 1 3 看到的是当下三秒的快照，不是“昨天下午 3 点卡顿那会儿”的记录。
真正能查历史的关键是系统是否启用了 sysstat 的日志轮转服务 —— 它会把每十分钟的统计写入 /var/log/sa/saXX（XX 是日期，如 sa15 表示 15 号）。
- 检查服务是否运行：
systemctl is-active sysstat，若返回inactive，则历史数据根本没在存 - 确认日志路径存在且有文件：
ls -l /var/log/sa/sa$(date -d yesterday +%d) - Ubuntu/Debian 默认可能未启用该服务，需手动执行
sudo systemctl enable --now sysstat
sar -u -f 读取指定日期 CPU 数据的正确姿势
想查 10 月 22 日的 CPU 使用率，不能只输 sar -u 22 —— 这会被解释为“每 22 秒采一次”，和日期无关。
必须用 -f 显式指定归档文件路径，且文件名严格对应日期格式：
- 查 10 月 22 日：运行
sar -u -f /var/log/sa/sa22（注意不是sa1022或sa-22） - 如果当天日志被压缩（常见于 logrotate 后），要先解压：
zcat /var/log/sa/sa22.gz | sar -u -f - -
-u默认只显示 %user、%nice、%system、%iowait、%idle；加-u ALL才能看到 %irq、%soft、%guest 等细分项
从 sar 输出快速定位卡顿发生时刻
sar 每行代表一个采样点（默认 10 分钟一次），但原始输出时间列不带日期，仅显示 HH:MM:SS，容易误判是今天还是昨天的数据。
- 加上
-s和-e可限定时间范围，例如查 22 日上午 10–12 点：sar -u -f /var/log/sa/sa22 -s 10:00:00 -e 12:00:00 - 高负载典型信号不止是 %idle 低，更要关注 %iowait > 30%（磁盘瓶颈）或 %soft > 20%（软中断过载，常见于网络收包风暴）
- 用
awk快速筛出异常行：sar -u -f /var/log/sa/sa22 | awk '$6 （找 %idle
为什么 sar -u 显示正常，但系统仍卡顿？
CPU 利用率只是表象。很多卡顿和 sar -u 无关，比如：
- 进程处于
D状态（不可中断睡眠），常因存储设备无响应，此时 %idle 可能很高，但ps aux | grep ' D '能看到挂起进程 - 内存耗尽触发频繁 swap，需配合
sar -r（内存）和sar -B（分页）交叉分析 - 单核饱和而整体 %idle 看似不低，用
sar -P ALL查各 CPU 核独立利用率，避免被平均值掩盖热点 -
sar默认采样间隔 10 分钟，错过秒级毛刺；真要抓瞬时峰值，得临时开sadf -d /var/log/sa/saXX | grep 'cpu.*[89][0-9]\|%idle.*[01][0-9]'
历史 sar 数据像行车记录仪，但只拍了主路——卡顿往往发生在没监控到的支路或瞬间，得结合 dmesg、journalctl --since '2024-10-22 14:30:00' 和应用自身日志才能闭环。
