查不到昨天cpu数据是因为sysstat服务未运行、日志文件缺失或cron未配置采集;需验证服务状态、检查saxx文件存在性、确认cron任务启用;sar -f必须置于选项最前才能读取历史数据。

查不到昨天的 CPU 数据?先确认 sysstat 是否真在存
不是 sar 不行,是没人给它存数据。默认情况下,sar 只能读取 /var/log/sysstat/saXX(如 sa14 表示 6 月 14 日)里的二进制归档,而这些文件由 sysstat 的后台服务生成。
执行以下三步快速验证:
-
systemctl is-active sysstat—— 必须返回active,否则服务没跑 -
ls -l /var/log/sysstat/sa$(date -d yesterday +%d)—— 比如今天 6 月 14 日,就查sa13;若报 “No such file”,说明昨天根本没采集 -
grep -v "^#" /etc/cron.d/sysstat | grep sa1—— 确保有类似*/10 * * * * root /usr/lib/sa/sa1 -S DISK 1 1的行,且未被注释
Ubuntu/Debian 安装后常默认禁用,得手动 sudo systemctl enable --now sysstat;最小化系统或容器里 cron 缺失,sa1 根本不会触发。
sar -u -f /var/log/sysstat/sa13 这样写才对
-f 是读历史数据的唯一入口,但它必须放在所有其他选项**前面**,顺序错了就当没写。
正确姿势:
- 查 6 月 13 日 CPU 使用率:
sar -f /var/log/sysstat/sa13 -u - 加细分项(比如看软中断):
sar -f /var/log/sysstat/sa13 -u ALL - 限定时间段(注意时间必须对齐采样粒度,默认 10 分钟):
sar -f /var/log/sysstat/sa13 -u -s 14:00:00 -e 15:00:00
常见错:
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
-
sar -u -f /var/log/sysstat/sa13——-f在后面,sar会忽略它,转而读当天缓存 -
sar -u 13—— 这会被解释为“每 13 秒采一次”,和日期无关 -
cat /var/log/sysstat/sa13—— 二进制文件,直接 cat 是乱码,必须用sar -f或sadf解析
%iowait 高 ≠ 磁盘慢,%idle 高也不代表不卡
sar -u 输出里最易误读的是 %iowait 和 %idle:
-
%iowait > 30%持续出现,大概率是存储响应慢(NFS 卡顿、RAID 降级、本地盘故障),但前提是 CPU 真空闲——如果此时%idle也很高,那确实是 I/O 等待;如果%idle很低,%iowait高就可能是统计偏差或内核 bug -
%idle低但系统不卡?可能单核饱和(用sar -P ALL -f /var/log/sysstat/sa13查各核) -
%idle高但系统卡死?立刻ps aux | grep ' D ',找不可中断睡眠进程(D 状态),通常是存储设备无响应
别只盯 %user + %system,真正有意义的 CPU 忙碌占比是 100 - %idle。
想定位卡顿发生时刻,别扫全量,要分层筛
原始 sar -u -f /var/log/sysstat/sa13 输出每行是 10 分钟一个点,靠肉眼翻很难抓到异常时刻。
高效做法:
- 先用
awk快速筛出%idle异常低的行:sar -f /var/log/sysstat/sa13 -u | awk '$6 (<code>$6是%idle列,依实际列序调整) - 再针对可疑时间段做精细截取:
sar -f /var/log/sysstat/sa13 -u -s 14:30:00 -e 15:00:00 - 交叉验证:同一时间跑
sar -r -f /var/log/sysstat/sa13(内存)、sar -b -f /var/log/sysstat/sa13(IO 吞吐),看指标是否同步尖刺
默认 10 分钟粒度会漏掉秒级毛刺;真要抓瞬时峰值,得提前配置 sa1 每秒采样(如 */1 * * * * root /usr/lib/sa/sa1 1 1),否则只能靠 top 或 pidstat 临时补位。










