Linux性能分析神器sar工具详解与实战

1. 为什么你需要掌握sar工具

在Linux系统运维和性能调优的日常工作中，我们经常会遇到各种"玄学"问题：服务器突然变慢、应用响应延迟、数据库查询卡顿...这时候新手往往会陷入两个极端——要么对着top命令的输出发呆，要么直接重启服务器了事。而真正的Linux老手，第一反应都是打开sar这个性能分析神器。

我见过太多工程师在性能问题面前抓瞎，根本原因就是没有系统性地掌握性能分析工具。sar（System Activity Reporter）作为Sysstat工具包的核心组件，能够提供从CPU、内存、IO到网络的全面系统活动报告。与top、vmstat等实时监控工具不同，sar的强大之处在于：

1. 历史数据分析能力：默认配置下会自动记录系统性能数据，让你可以回溯分析问题发生时的系统状态
2. 全维度监控覆盖：单个工具就能监控CPU、内存、磁盘、网络等所有关键指标
3. 低开销：数据收集进程sysstat的资源占用几乎可以忽略不计
4. 灵活的时间粒度：支持从秒级到天级的各种采样间隔

提示：很多生产环境的事故复盘都依赖sar的历史数据。如果没有提前安装配置好sysstat，等到出问题时才想起来要监控，那就真的只能靠"猜"了。

2. sar的安装与基础配置

2.1 安装sysstat工具包

在大多数Linux发行版中，sar都包含在sysstat包中。安装方法如下：

# Ubuntu/Debian sudo apt update && sudo apt install sysstat -y # CentOS/RHEL sudo yum install sysstat -y # 验证安装 sar -V

安装完成后，需要确认数据收集服务是否已启用：

# 检查服务状态（systemd系统） sudo systemctl status sysstat # 如果未运行，启用并启动服务 sudo systemctl enable --now sysstat

2.2 关键配置项解析

sysstat的主要配置文件位于/etc/sysconfig/sysstat或/etc/default/sysstat，几个重要参数需要特别关注：

# 历史数据保存天数（默认7天） HISTORY=28 # 数据收集频率（默认10分钟） SADC_OPTIONS="-S DISK 10 3" # 是否压缩历史数据（建议开启） COMPRESSAFTER=15

建议将HISTORY调整为至少14天，这样能够覆盖两个周末的业务周期。对于关键业务服务器，可以设置为30天甚至更长。

2.3 数据文件存储结构

sysstat收集的数据默认存储在/var/log/sa/目录下，文件命名规则为：

• saDD：二进制格式的每日数据文件（DD表示日期）
• sarDD：文本格式的每日报告

例如sa10对应当月10号的数据，可以通过sar -f /var/log/sa/sa10命令读取。

3. sar核心功能实战解析

3.1 CPU性能分析

3.1.1 整体CPU使用率

# 查看当天CPU使用情况（10分钟间隔） sar -u # 查看指定日期的CPU数据 sar -u -f /var/log/sa/sa10 # 实时监控（每2秒采样，共5次） sar -u 2 5

输出字段解析：

• %user：用户态CPU时间
• %system：内核态CPU时间
• %iowait：等待I/O的CPU时间
• %steal：虚拟化环境中的CPU抢占时间
• %idle：空闲CPU时间

经验法则：如果%iowait持续高于5%，说明磁盘可能成为瓶颈；%idle持续低于20%则CPU资源紧张。

3.1.2 多核CPU分析

# 查看所有CPU核心的统计 sar -P ALL # 只看第一个CPU核心（CPU0） sar -P 0 # 按核心显示用户态使用率 sar -u -P ALL | grep -v 'Average'

在多核服务器上，需要特别关注CPU使用是否均衡。我曾经遇到过一个案例：某个应用线程绑定到了特定核心，导致8核CPU中有一个核心100%满载，而其他核心却很空闲，整体%idle看起来很正常，但实际性能已经受到影响。

3.2 内存使用分析

3.2.1 物理内存与交换空间

# 查看内存使用情况 sar -r # 只显示内存相关指标 sar -r 1 3

关键指标：

• kbmemfree：空闲物理内存（KB）
• kbmemused：已用物理内存
• %memused：内存使用率
• kbswpfree：空闲交换空间
• kbswpused：已用交换空间

3.2.2 内存分页统计

# 内存分页活动监控 sar -B # 每秒采集一次，共5次 sar -B 1 5

重要字段：

• pgpgin/s：每秒从磁盘换入的页数
• pgpgout/s：每秒换出到磁盘的页数
• fault/s：每秒缺页异常数（major + minor）

避坑提示：如果pgpgin/s和pgpgout/s持续高于几百，说明系统在进行大量内存交换，性能会显著下降。这时候应该考虑增加物理内存或优化应用内存使用。

3.3 磁盘I/O分析

3.3.1 整体磁盘负载

# 查看磁盘I/O统计 sar -b # 每2秒采样，共3次 sar -b 2 3

输出解读：

• tps：每秒传输次数（IOPS）
• rtps：每秒读请求数
• wtps：每秒写请求数
• bread/s：每秒读取的块数（512B）
• bwrtn/s：每秒写入的块数

3.3.2 单个磁盘设备分析

# 显示每个块设备的详细统计 sar -d -p # 指定设备名查看（如sda） sar -d -p | grep sda

关键性能指标：

• await：平均I/O等待时间（ms）
• svctm：平均服务时间（ms）
• %util：设备利用率

性能诊断：await远大于svctm表示I/O队列过长；%util接近100%表示设备饱和。我曾经通过这个指标发现一个SSD磁盘因为寿命将至导致svctm从正常的0.5ms飙升到15ms。

3.4 网络流量监控

3.4.1 网络接口统计

# 查看网络设备统计 sar -n DEV # 监控特定网卡（如eth0） sar -n DEV | grep eth0

核心指标：

• rxpck/s：每秒接收包数
• txpck/s：每秒发送包数
• rxkB/s：每秒接收数据量（KB）
• txkB/s：每秒发送数据量（KB）

3.4.2 TCP连接统计

# TCP连接监控 sar -n TCP # 查看TCP错误统计 sar -n ETCP

重点关注：

• active/s：每秒本地发起的TCP连接
• passive/s：每秒远程发起的TCP连接
• retrans/s：每秒TCP重传数

4. 高级技巧与实战案例

4.1 历史数据分析方法

4.1.1 查看特定时间段数据

# 查看昨天10:00到12:00的CPU数据 sar -u -f /var/log/sa/sa$(date -d yesterday +%d) -s 10:00:00 -e 12:00:00 # 查看本月5号9点到10点的内存使用 sar -r -f /var/log/sa/sa05 -s 09:00:00 -e 10:00:00

4.1.2 生成可视化报告

虽然sar本身是命令行工具，但我们可以结合其他工具生成可视化图表：

# 将CPU数据导出为CSV sar -u -f /var/log/sa/sa10 | grep -v '^$' | grep -v 'Linux' | tr -s ' ' ',' > cpu.csv # 用gnuplot绘图（需要提前安装） echo "set terminal png; set output 'cpu.png'; plot 'cpu.csv' using 1:3 title 'User%' with lines, '' using 1:5 title 'System%' with lines" | gnuplot

4.2 性能问题诊断流程

根据多年经验，我总结了一个sar性能分析四步法：

1. 定方向：通过sar -q查看系统负载，sar -u确认CPU瓶颈
2. 查细节：如果CPU高，用sar -P ALL看是否某个核心异常；如果负载高但CPU不高，查内存sar -r和IOsar -b
3. 找关联：对比问题时间点的各项指标变化，找出最先出现异常的指标
4. 验假设：通过历史数据验证是否是周期性现象或偶发问题

4.3 生产环境案例分析

案例1：数据库查询突然变慢

• 现象：每天下午3点，MySQL查询响应变慢
• 分析过程：
  1. 用sar -r -f /var/log/sa/sa10发现内存在3点时%memused达到95%
  2. sar -B显示此时pgscank/s很高，说明kswapd在频繁工作
  3. 结合sar -d发现磁盘%util达到100%
  4. 结论：内存不足导致频繁交换，磁盘成为瓶颈
• 解决方案：增加数据库缓冲池配置，添加服务器内存

案例2：API接口间歇性超时

• 现象：随机出现API响应超时，持续时间1-2分钟
• 分析过程：
  1. 通过sar -n DEV发现网络rxpck/s在超时时段异常高
  2. sar -n TCP显示retrans/s同时飙升
  3. 进一步用sar -A全面检查发现是某个后台任务在大量传输数据
• 解决方案：对后台任务实施限流，优化数据传输方式

5. 常见问题与解决方案

5.1 数据收集相关问题

Q：sar命令显示"No data available"？

A：可能原因和解决方法：

1. sysstat服务未运行 → 启动服务systemctl start sysstat
2. 数据收集间隔太长 → 修改SADC_OPTIONS为更短间隔（如1分钟）
3. 磁盘空间不足 → 清理旧的日志文件

Q：如何调整数据收集的时间间隔？

编辑/etc/sysconfig/sysstat，修改：

# 每1分钟收集一次，保存3个样本 SADC_OPTIONS="-S DISK 1 3"

然后重启sysstat服务。

5.2 性能分析常见误区

1. 只看平均值：sar默认显示平均值，可能掩盖瞬时峰值。建议用-i参数指定更短间隔，或查看原始数据文件。

2. 孤立看待指标：CPU高不一定是CPU问题，可能是内存不足导致频繁交换。要综合多个指标分析。

3. 忽略历史基线：没有建立系统正常时的性能基线，导致无法判断当前是否真的异常。建议定期保存典型工作日的sar报告作为参考。

4. 过度依赖%util：对于SSD等现代存储设备，%util达到100%不一定是问题，需要结合await等指标综合判断。

5.3 性能优化建议

1. CPU密集型应用：

   • 关注%user和%system比例
   • 考虑使用taskset或cgroups进行CPU绑定

2. 内存敏感型应用：

   • 监控kbmemfree和kbswpused
   • 调整vm.swappiness参数减少交换

3. IO密集型负载：

   • 关注await和svctm的差值
   • 考虑使用IO调度器调优（如deadline改为noop）

4. 网络服务：

   • 监控retrans/s等TCP错误指标
   • 调整TCP缓冲区大小等内核参数

6. 扩展工具与生态系统

6.1 与sar配合使用的工具

1. iostat：更详细的磁盘I/O统计
2. mpstat：更细致的CPU统计
3. pidstat：进程级别的资源监控
4. nmon：交互式系统监控工具

6.2 图形化前端工具

1. ksar：Java编写的sar数据可视化工具

   java -jar ksar.jar -input /var/log/sa/sa10

2. sadf：sysstat自带的报表生成工具

   sadf -d /var/log/sa/sa10 -- -u | gnuplot

6.3 企业级监控集成

1. Prometheus + node_exporter：通过textfile收集器导入sar数据
2. ELK Stack：使用Filebeat收集sar日志进行分析
3. Grafana：可视化sar历史数据

在实际工作中，我通常会将sar与这些工具结合使用。比如先用sar快速定位问题方向，再用更专业的工具深入分析具体问题。对于长期监控，则建议将关键sar指标集成到企业监控系统中。