Linux ar 工具的使用场景

查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/ 看有没有最新文件，比什么都实在。