CPU使用率是否真高不能只看%user，需结合%iowait（磁盘等待）、%soft（软中断）等指标综合判断；%iowait高而%idle也高说明I/O等待，非CPU忙；%soft持续>15%需查网卡队列或中断绑定。
怎么看 CPU 使用率是否真高？别只盯 %user
很多人看到 sar -u 输出里 %user 超过 70% 就断定 CPU 瓶颈，其实容易误判。真实压力可能藏在 %iowait 或 %soft 里——前者说明磁盘慢拖住了 CPU，后者意味着网络/中断处理过载。
实操建议：
- 用
sar -u 1 5每秒采样 5 次，观察各指标波动趋势，单次峰值意义不大 - 如果
%iowait高但%idle也高，大概率是进程在等 I/O，不是 CPU 真忙 -
%soft持续 > 15%，要查网卡队列、软中断绑定（/proc/interrupts）或 netfilter 规则 - 注意：默认
sar不显示%guest，加-u ALL才能看到虚拟机开销
sar -r 显示的 %memused 为什么和 free 对不上？
因为 sar -r 的 %memused = (MemTotal − MemFree − Buffers − Cached) / MemTotal，而 free 默认把 Cached 和 Buffers 算进“可用”内存。两者统计口径不同，不是 bug。
实操建议：
- 看内存压力，重点盯
kbmemfree是否持续低于 5% 的MemTotal，而不是%memused数值本身 -
sar -r不显示 slab 内存，遇到 OOM 前兆，要补看sar -w（pgpgin/pgpgout）和/proc/meminfo中Slab、SReclaimable - 避免用
sar -r判断是否该扩容——它不反映应用实际 RSS，得结合pmap -x或smaps_rollup
磁盘 I/O 分析时，sar -d 的 await 和 %util 哪个更可信？
%util 是设备忙时间占比，对 NVMe 或多队列 SCSI 盘已基本失效——它们能并行处理数百请求，%util 达到 100% 只代表有请求在飞，不代表饱和。await（平均每次 I/O 耗时）才是关键延迟指标。
实操建议：
- SSD 场景下，
await > 10ms就值得排查；HDD 则看是否持续 > 50ms -
sar -d默认不显示队列深度，加-d -p（-p为友好设备名）再配合cat /sys/block/*/queue/nr_requests才能判断是否压满 - 注意：如果
svctm字段为空（显示为-），说明内核未提供服务时间，此时await≈svctm+ 排队时间，但无法拆分 - 用
sar -d 1 5时，第一行是系统启动以来均值，忽略；从第二行开始看实时趋势
历史数据怎么查？/var/log/sa/ 文件不是直接文本
sar 的历史数据存在二进制文件里（如 /var/log/sa/sa25 表示当月 25 日），不能 cat 查看。直接读会输出乱码，强行解析还可能因内核版本差异出错。
实操建议：
- 查某天数据，用
sar -f /var/log/sa/sa25，支持所有sar参数（如sar -f /var/log/sa/sa25 -u 1） - sa 日志默认只保留 7 天，修改
/etc/cron.d/sysstat中remove行的数字，或用find /var/log/sa -name "sa[0-9]*" -mtime +30 -delete自定义清理 - 跨日聚合分析？别拼接二进制文件。先用
sar -f导出为 CSV：sar -f /var/log/sa/sa25 -u | awk '{print $1","$3","$4","$5","$6}' > cpu-25.csv - 注意：
sadf工具可导出 JSON/CSV，但需 sysstat ≥ 12.0.0，老系统（如 CentOS 7）默认不带
/proc/sys/kernel/perf_event_paranoid 设置，设为 2 以上时，sar -n DEV 的网卡错误计数可能不准，但这点连 man page 都没明说。 
