1. 初识Linux性能分析神器sar
作为一名运维老兵，我至今还记得第一次真正认识到sar威力的那个深夜。当时线上服务出现间歇性卡顿，我们用遍了各种实时监控工具都找不到原因，直到翻出sar的历史数据，才发现每天凌晨3点15分有个定时任务在疯狂消耗CPU资源。那一刻，这个看似普通的命令行工具在我眼中瞬间变得无比耀眼。
sar（System Activity Reporter）是Linux系统自带的性能分析工具，属于sysstat工具包的一部分。它就像给服务器装了个全天候工作的黑匣子，默默记录着CPU、内存、磁盘、网络等关键指标的历史数据。与其他实时监控工具不同，sar最强大的地方在于它能让你"穿越时空"查看过去任意时刻的系统状态。
1.1 sar的核心价值解析
为什么我强烈推荐每个Linux系统管理员都要掌握sar？主要基于以下几个不可替代的优势：
-
历史数据分析能力：能够回溯查看过去任意时间点的系统状态，这对诊断间歇性故障至关重要。比如用户反馈"昨天下午系统很卡"，你就能用sar还原当时的系统状况。
-
全面的监控维度：覆盖CPU、内存、磁盘、网络、进程等几乎所有关键系统指标，不需要安装多个工具来回切换。
-
极低的开销：数据收集进程(sadc)经过特别优化，对系统性能影响微乎其微，适合长期运行。
-
灵活的报表生成：支持按时间范围筛选数据，并能导出为多种格式供后续分析。
-
广泛的兼容性：几乎预装在所有主流Linux发行版中，不需要额外安装配置就能使用。
1.2 sar与其他监控工具的对比
在Linux性能分析领域，我们有很多工具可选，下表展示了sar与其他常见工具的对比：
| 工具名称 | 实时监控 | 历史数据 | 监控维度 | 学习曲线 | 典型使用场景 |
|---|---|---|---|---|---|
| sar | 支持 | 支持 | 全面 | 中等 | 综合性能分析、历史问题排查 |
| top | 支持 | 不支持 | 基础 | 简单 | 快速查看当前系统状态 |
| htop | 支持 | 不支持 | 基础+ | 简单 | 交互式进程监控 |
| vmstat | 支持 | 不支持 | 中等 | 中等 | 内存和CPU快速检查 |
| iostat | 支持 | 不支持 | 磁盘IO | 中等 | 磁盘性能分析 |
| nmon | 支持 | 支持 | 全面 | 中等 | 交互式综合监控 |
从对比可以看出，sar在历史数据支持和监控全面性方面具有明显优势，特别适合需要深入分析系统性能的场景。
2. sar的安装与基础配置
2.1 安装sysstat工具包
虽然大多数Linux发行版都预装了sysstat，但如果你的系统没有，安装也非常简单：
对于RHEL/CentOS系统：
bash复制# 老版本使用yum
yum install sysstat
# CentOS 8+/RHEL 8+使用dnf
dnf install sysstat
对于Debian/Ubuntu系统：
bash复制apt-get install sysstat
安装完成后，需要启用并启动数据收集服务：
bash复制systemctl enable sysstat
systemctl start sysstat
2.2 理解sar的数据收集机制
sar的数据收集由两个主要组件完成：
- sadc（System Activity Data Collector）：负责定时收集系统指标并存储到二进制文件中。
- sa1/sa2：sadc的包装脚本，通常通过cron定时运行。
默认配置下，sar每10分钟收集一次完整数据（通过/etc/cron.d/sysstat中的sa1脚本），每天23:53生成每日摘要报告（通过sa2脚本）。
数据文件存储在/var/log/sa/目录下，命名规则为：
- saDD：每天的详细数据文件（DD代表日期）
- sarDD：每天的摘要报告文件
2.3 自定义数据收集频率
如果需要更频繁的数据收集，可以编辑/etc/cron.d/sysstat文件。例如，要改为每5分钟收集一次：
bash复制# 将原来的10分钟间隔改为5分钟
*/5 * * * * root /usr/lib64/sa/sa1 1 1
修改后需要重启sysstat服务：
bash复制systemctl restart sysstat
注意：增加收集频率会占用更多磁盘空间。在默认配置下，每天的数据文件大约占用2-3MB空间，如果改为每分钟收集一次，空间占用将增加约10倍。
2.4 数据文件管理策略
长期运行的服务器上，sar的历史数据可能会占用大量磁盘空间。通过编辑/etc/sysconfig/sysstat文件，可以调整数据保留策略：
bash复制# 保留最近7天的数据
HISTORY=7
# 压缩超过2天的数据
COMPRESSAFTER=2
对于已经存在的旧数据，可以使用sa工具进行清理：
bash复制# 删除10天前的数据文件
find /var/log/sa -name "sa[0-9]*" -mtime +10 -exec rm -f {} \;
find /var/log/sa -name "sar[0-9]*" -mtime +10 -exec rm -f {} \;
3. sar核心功能实战详解
3.1 CPU性能分析
CPU是系统最重要的资源之一，sar提供了多种视角来监控CPU使用情况。
3.1.1 基本CPU监控
使用-u参数查看CPU使用率：
bash复制# 每1秒采样一次，共采样5次
sar -u 1 5
典型输出：
code复制03:25:01 PM CPU %user %nice %system %iowait %steal %idle
03:25:02 PM all 2.50 0.00 1.25 0.00 0.00 96.25
03:25:03 PM all 3.75 0.00 1.25 0.00 0.00 95.00
各字段含义：
- %user：用户态CPU使用率（应用程序消耗的CPU）
- %nice：低优先级用户态CPU使用率
- %system：内核态CPU使用率
- %iowait：CPU等待I/O的时间百分比
- %steal：虚拟化环境下被其他虚拟机占用的CPU时间
- %idle：CPU空闲时间百分比
关键指标解读：
- 如果%user持续高于80%，说明应用程序是CPU瓶颈
- %system高于20%可能表明内核存在瓶颈或系统调用过多
- %iowait高通常意味着磁盘I/O成为瓶颈
- 在虚拟化环境中，%steal高表示物理主机资源不足
3.1.2 多核CPU监控
对于多核系统，使用-P ALL参数查看每个核心的使用情况：
bash复制sar -P ALL 1 3
输出示例：
code复制03:30:01 PM CPU %user %nice %system %iowait %steal %idle
03:30:02 PM all 5.00 0.00 2.50 0.00 0.00 92.50
03:30:02 PM 0 8.00 0.00 4.00 0.00 0.00 88.00
03:30:02 PM 1 2.00 0.00 1.00 0.00 0.00 97.00
这个视图能帮助我们发现CPU负载不均衡的问题。我曾经遇到过一个Java应用因为错误配置了线程池，导致所有计算都集中在单个CPU核心上，其他核心却闲置的情况。
3.1.3 上下文切换监控
使用-w参数监控进程上下文切换：
bash复制sar -w 1 5
输出示例：
code复制03:35:01 PM proc/s cswch/s
03:35:02 PM 0.00 1234.56
- proc/s：每秒创建的进程数
- cswch/s：每秒上下文切换次数
如果cswch/s持续很高（比如超过10000），可能表明系统存在进程调度问题，通常是由于过多进程竞争CPU资源导致的。
3.2 内存使用分析
3.2.1 基本内存监控
使用-r参数查看内存使用情况：
bash复制sar -r 1 5
输出示例：
code复制03:40:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
03:40:02 PM 1048576 3145728 75.00 102400 524288 2621440 62.50
关键指标：
- kbmemfree：空闲物理内存（KB）
- kbmemused：已使用物理内存（KB）
- %memused：内存使用百分比
- kbbuffers：内核缓冲区使用的内存
- kbcached：页面缓存使用的内存
- kbcommit：当前工作负载所需的内存总量
- %commit：kbcommit占内存+swap总量的百分比
重要提示：Linux会充分利用空闲内存作为缓存，因此%memused高不一定表示内存不足。真正需要关注的是当应用程序需要内存时，系统能否快速回收这些缓存。
3.2.2 Swap空间监控
使用-S参数监控Swap使用情况：
bash复制sar -S 1 5
输出示例：
code复制03:45:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
03:45:02 PM 2097148 0 0.00 0 0.00
当%swpused开始显著增加（比如超过10%），通常表明物理内存已经不足，系统开始频繁使用Swap，这会导致明显的性能下降。
3.2.3 内存分页监控
使用-B参数查看内存分页情况：
bash复制sar -B 1 5
输出示例：
code复制03:50:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s
03:50:02 PM 0.00 5.25 123.45 0.00 456.78 0.00 0.00
关键指标：
- pgpgin/s：每秒从磁盘读入的页数
- pgpgout/s：每秒写入磁盘的页数
- majflt/s：每秒发生的主要缺页错误数（需要从磁盘读取）
如果majflt/s持续很高，说明系统正在经历大量硬盘I/O来满足内存需求，这通常会导致性能问题。
3.3 磁盘I/O性能分析
3.3.1 基本磁盘监控
使用-d参数监控磁盘I/O：
bash复制sar -d 1 5
输出示例：
code复制03:55:01 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
03:55:02 PM dev8-0 15.84 0.00 253.47 16.00 0.02 1.25 0.63 10.00
关键指标解析：
- tps：每秒I/O传输次数（IOPS）
- rd_sec/s, wr_sec/s：每秒读写扇区数（1扇区=512B）
- avgrq-sz：平均每次I/O请求的大小（扇区）
- avgqu-sz：平均I/O队列长度
- await：平均I/O等待时间（毫秒）
- svctm：平均I/O服务时间（毫秒）
- %util：设备利用率百分比
经验法则：
- 对于机械硬盘，await超过20ms通常表示磁盘负载过高
- 对于SSD，await超过5ms就需要注意
- %util接近100%表示磁盘已经饱和
3.3.2 按分区查看I/O
使用-p参数以分区名显示（更易读）：
bash复制sar -d -p 1 5
输出示例：
code复制04:00:01 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
04:00:02 PM sda1 5.00 0.00 40.00 8.00 0.01 2.00 1.00 5.00
3.3.3 磁盘负载均衡检查
在多磁盘系统中，可以使用sar检查负载是否均衡：
bash复制sar -d 1 5 | grep -v "DEV" | awk '{print $1,$10}' | sort -k2 -nr
这个命令会按%util降序排列磁盘设备，快速找出最繁忙的磁盘。
3.4 网络性能监控
3.4.1 网络接口统计
使用-n DEV查看网络接口统计：
bash复制sar -n DEV 1 5
输出示例：
code复制04:05:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
04:05:02 PM eth0 125.74 89.11 78.32 15.67 0.00 0.00 0.50
关键指标：
- rxpck/s, txpck/s：每秒收/发包数量
- rxkB/s, txkB/s：每秒收/发数据量（KB）
- rxmcst/s：每秒接收的多播包数
典型问题识别：
- rxpck/s高但rxkB/s低：可能受到小包攻击
- txkB/s接近接口带宽上限：网络出口带宽饱和
- rxpck/s接近网卡处理能力上限：可能需要更高效的网卡或驱动优化
3.4.2 TCP连接统计
使用-n TCP查看TCP连接状态：
bash复制sar -n TCP 1 5
输出示例：
code复制04:10:01 PM active/s passive/s iseg/s oseg/s
04:10:02 PM 12.34 5.67 1234.56 987.65
关键指标：
- active/s：本地发起的每秒TCP连接数
- passive/s：远程发起的每秒TCP连接数
- iseg/s：每秒接收的TCP段数
- oseg/s：每秒发送的TCP段数
这个视图对Web服务器特别有用，可以观察连接建立速率和网络流量。
3.4.3 网络错误统计
使用-n EDEV查看网络错误：
bash复制sar -n EDEV 1 5
输出示例：
code复制04:15:01 PM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s
04:15:02 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
网络错误率上升通常表明存在硬件问题、驱动问题或网络拥塞。
4. sar高级技巧与实战案例
4.1 历史数据分析技巧
4.1.1 查看特定日期的数据
sar的历史数据文件存储在/var/log/sa/目录下，命名格式为saDD（DD代表日期）。要查看某天的数据，使用-f参数：
bash复制# 查看15号的数据
sar -u -f /var/log/sa/sa15
4.1.2 指定时间范围分析
使用-s和-e参数限定时间范围：
bash复制# 查看15号上午9点到11点的CPU使用率
sar -u -f /var/log/sa/sa15 -s 09:00:00 -e 11:00:00
4.1.3 生成综合报告
使用-A参数生成包含所有统计信息的综合报告：
bash复制sar -A -f /var/log/sa/sa15 > system_report_15.txt
这个报告文件可以存档，作为系统性能的长期记录。
4.2 性能问题诊断案例
案例1：间歇性CPU高负载问题
现象：用户报告每天下午系统响应变慢，但运维团队检查时系统正常。
诊断过程：
- 使用sar查看历史CPU数据：
bash复制sar -u -f /var/log/sa/sa14 -s 12:00:00 -e 18:00:00
- 发现每天14:00-14:15期间%system异常升高
- 结合sar -q查看负载平均值，确认系统负载确实增加
- 检查crontab发现一个定时备份脚本在每天14:00运行
- 使用sar -d确认备份期间磁盘I/O激增
解决方案：调整备份脚本的执行时间到夜间低峰期。
案例2：内存泄漏问题
现象：系统运行一段时间后响应变慢，重启后恢复正常。
诊断过程：
- 使用sar -r查看多天的内存使用趋势：
bash复制sar -r -f /var/log/sa/sa13
sar -r -f /var/log/sa/sa14
- 发现kbmemused呈现稳定上升趋势，即使业务量没有增加
- 结合sar -S发现Swap使用量也在逐步增加
- 使用ps aux --sort=-%mem找出内存占用最高的进程
- 确认是某个Java应用存在内存泄漏
解决方案：修复应用内存泄漏问题，并设置合理的JVM内存参数。
4.3 sar与其他工具集成
4.3.1 与监控系统集成
sar的数据可以定期导出并导入到监控系统如Zabbix中。示例脚本：
bash复制#!/bin/bash
# 获取昨天的CPU平均使用率
CPU_USE=$(sar -u -f /var/log/sa/sa$(date -d yesterday +%d) | grep "Average" | awk '{print 100-$NF}')
# 发送到Zabbix
zabbix_sender -z zabbix_server -k "cpu.avg.use" -o $CPU_USE
4.3.2 自动化报表生成
可以创建定期运行的脚本，生成每日性能报告并发送邮件：
bash复制#!/bin/bash
REPORT_FILE="/tmp/daily_performance_report_$(date +%Y%m%d).txt"
echo "===== 每日系统性能报告 $(date -d yesterday +%Y-%m-%d) =====" > $REPORT_FILE
echo "" >> $REPORT_FILE
echo "CPU平均使用率：" >> $REPORT_FILE
sar -u -f /var/log/sa/sa$(date -d yesterday +%d) | grep "Average" >> $REPORT_FILE
echo "" >> $REPORT_FILE
echo "内存使用情况：" >> $REPORT_FILE
sar -r -f /var/log/sa/sa$(date -d yesterday +%d) | grep "Average" >> $REPORT_FILE
echo "" >> $REPORT_FILE
mail -s "系统性能日报" admin@example.com < $REPORT_FILE
5. sar使用中的常见问题与解决方案
5.1 数据文件相关问题
问题1：sar报告"No data available"
可能原因：
- sysstat服务未运行
- /var/log/sa/目录不存在或权限不正确
- 磁盘空间不足导致数据收集失败
解决方案：
bash复制# 检查服务状态
systemctl status sysstat
# 确保目录存在并有正确权限
mkdir -p /var/log/sa
chown -R root:root /var/log/sa
chmod 755 /var/log/sa
# 检查磁盘空间
df -h /var/log
问题2：sar历史数据文件损坏
现象：使用-f参数查看历史数据时出现错误。
解决方案：
- 尝试使用sar的-q参数（静默模式）读取：
bash复制sar -q -f /var/log/sa/sa15
- 如果仍然失败，只能删除损坏的文件（无法修复）：
bash复制rm -f /var/log/sa/sa15
5.2 性能影响问题
问题：sar数据收集影响系统性能
解决方案：
- 降低数据收集频率（修改/etc/cron.d/sysstat）
- 减少收集的指标（编辑/etc/sysconfig/sysstat）
- 对高负载系统，考虑使用更轻量级的监控方案
5.3 数据解读常见误区
误区1：%memused高就是内存不足
事实：Linux会充分利用空闲内存作为缓存，高%memused通常不是问题，除非伴随以下情况：
- Swap使用量持续增加
- 主要缺页错误(majflt)频繁发生
- 应用程序因内存不足而报错
误区2：%util 100%就是磁盘瓶颈
事实：对于现代SSD和RAID阵列，%util可能达到100%但仍有处理能力，应该结合await和svctm指标综合判断：
- 高%util + 高await = 真正的磁盘瓶颈
- 高%util + 低await = 磁盘能够处理负载
6. sar的最佳实践指南
6.1 日常监控建议
- 建立基线：在系统正常运行时收集1-2周的sar数据，建立性能基线
- 定期检查：设置每日/每周性能报告，主动发现问题
- 关键指标警报：对CPU、内存、磁盘等关键指标设置阈值警报
6.2 性能问题排查流程
- 确定问题时间范围：尽可能精确地定位问题发生的时间段
- 从整体到局部：
- 先看整体CPU、内存、磁盘、网络使用情况
- 然后深入分析异常的子系统和具体设备
- 关联分析：将不同指标关联起来看（如高CPU iowait时检查磁盘活动）
- 对比基线：将异常数据与正常时期的基线数据进行对比
6.3 长期性能优化策略
- 趋势分析：定期分析sar历史数据，识别性能的长期变化趋势
- 容量规划：基于历史增长数据预测未来的资源需求
- 配置调优：根据sar揭示的瓶颈点，针对性调整系统参数
7. 总结与进阶学习建议
经过本文的详细介绍，相信你已经掌握了sar这个强大工具的核心用法。作为Linux系统性能分析的瑞士军刀，sar的价值不仅在于它能提供全面的系统监控数据，更在于它能让你拥有"时光倒流"的能力，去诊断那些难以复现的间歇性性能问题。
在实际工作中，我建议你：
- 从基础开始：先熟练掌握CPU、内存、磁盘、网络这四大核心模块的监控
- 建立个人知识库：将常见问题的诊断过程和解决方案记录下来
- 结合其他工具：将sar与top、vmstat、iostat等工具配合使用
- 自动化常规任务：编写脚本自动收集关键指标并生成报告
记住，工具只是手段，真正重要的是培养系统化的性能分析思维。每个指标变化背后都有其原因，而sar就是帮助你发现这些原因的有力工具。