查CPU瓶颈时需结合%sar -u中%iowait与%idle：%idle高但响应卡顿，若%iowait>5%则立即查磁盘；sar -r比free更能反映内存真实压力，kbavail比kbmemfree更可靠；sar -d与sar -b需联用分析I/O，await>20ms且%util>90%表明磁盘饱和；sar -n DEV是唯一可回溯历史网络异常的命令，排查前须确认sysstat已启用并正常采集数据。
查CPU瓶颈时，sar -u 要看 %iowait 和 %idle 的组合含义
单独看 %idle 高 ≠ 系统健康。比如 %idle=95 但响应卡顿，很可能是 CPU 在等内存分配（缺内存）或磁盘慢导致线程阻塞；此时 %iowait 若持续 >5%，就要立刻查磁盘 —— 它比 top 的 CPU 占用率更能暴露 I/O 瓶颈。
-
sar -u 2 10实时抓 10 次、每 2 秒一采，适合排查突发高负载 - 历史分析用
sar -u -f /var/log/sa/sa23（23 号数据），注意文件名是sa+ 日期，不是sar - 多核机器加
-P ALL（如sar -P ALL 1 5）可定位单核打满问题，避免被all平均值掩盖热点
诊断内存压力，sar -r 比 free 更反映真实水位
free 显示的是当前快照，而 sar -r 记录的是周期性采样下的内存页回收、缓存膨胀、交换活动趋势 —— 尤其当 %memused 接近 95% 且 kbmemfree 长期低于 100MB，再结合 sar -B 中的 pgmajfault/s（大页缺页）飙升，基本可断定应用在频繁触发 OOM killer 或 swap。
- 默认日志只保留 28 天（
history=28在/etc/sysconfig/sysstat），查更久需提前配置 -
kbavail比kbmemfree更可靠，它包含可立即回收的 cache/buffer，是内核实际可用内存 - 如果
sar -r显示kbcommit持续 >100%，说明系统已过度承诺内存，风险极高
分析磁盘 I/O 性能，sar -d 和 sar -b 必须一起看
sar -d 给出设备级吞吐（rkB/s, wkB/s）、队列深度（aqu-sz）、响应延迟（await）；sar -b 则反映整体块层效率（tps, rd_sec/s, wr_sec/s）。若 await > 20ms 且 %util > 90%，说明磁盘饱和；但若 %util 很低而 await 高，大概率是上层应用并发写入太猛（如数据库日志刷盘），而非磁盘本身慢。
-
sar -d默认不显示设备名（如sda），需确认内核启用SADC_OPTIONS="-S DISK"（见/etc/sysconfig/sysstat） - 云服务器常见陷阱：
dev253-0这类 device-mapper 名称，要结合lsblk或cat /proc/diskstats对应到真实云盘 - SSD 场景下
svctm已无意义（被内核废弃），专注await和aqu-sz
回溯网络异常，sar -n DEV 是唯一能查“昨天下午三点丢包”的命令
不像 iftop 或 netstat 只能看实时，sar -n DEV 的历史记录保存在 /var/log/sa/ 下，可精确到分钟级还原流量突增、接口错包、广播风暴。关键字段：rxpck/s（收包率）、txerr/s（发包错误）、rxdrop/s（接收丢包）—— 如果某时段 rxdrop/s 突然跳升，大概率是网卡 buffer 溢出或驱动问题。
- 必须确保
sysstat的 cron 任务正常运行（检查systemctl status sysstat和/var/log/sa/下是否有新文件） -
sar -n DEV -f /var/log/sa/sa22查 22 号数据，但注意：默认只存最近 28 天，过期自动清理 - 云环境要注意虚拟网卡命名（如
ens3,eth0），不同厂商命名规则不同，别认错接口
实际排查中，最常被忽略的是：sar 数据是否真在采集 —— 很多机器装了 sysstat 却没改 ENABLED="true"，或者 cron 被禁用，结果查半天历史数据全是空的。动手前先跑 ls -lt /var/log/sa/ 看有没有最新文件，比什么都实在。