Linux下Sar查看CPU利用率定位卡顿点

本文深入解析了Linux下如何正确使用sar命令定位系统卡顿问题，重点澄清了sar默认不保存历史数据的常见误区，强调sysstat服务启用与日志轮转机制对回溯分析的关键作用；详细演示了通过-f参数精准读取指定日期CPU归档数据（如sa22）、结合-s/-e限定时间范围、利用awk快速筛选高负载时刻等实战技巧，并指出仅看%idle易误判——需综合%iowait、%soft、单核利用率（-P ALL）、D状态进程、内存与分页活动等多维度指标交叉验证，最终揭示卡顿真相往往藏在sar未覆盖的瞬时毛刺或底层硬件/内核事件中，必须联动dmesg、journalctl和应用日志才能完成完整诊断闭环。

为什么 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' 和应用自身日志才能闭环。

以上就是《Linux下Sar查看CPU利用率定位卡顿点》的详细内容，更多关于的资料请关注golang学习网公众号！