别再瞎猜了！一篇文章让你彻底搞定Linux性能分析神器sar

昨天晚上又被客户叫去处理线上问题，服务器连不上，重启后排查是什么导致故障，我在那里一顿操作猛如虎，top、free、iostat轮番上阵，但总感觉看不到全貌。后来想起来用sar一分析，嘿，问题马上就清楚了。

说起sar这个工具，可能很多朋友都听过，但真正用好的人不多。我刚开始做运维那会儿，也是对这玩意儿一知半解，总觉得它输出的数据太多太杂，看着头疼。直到有一次处理一个诡异的性能问题，其他工具都没找到根因，最后靠sar的历史数据才定位到了问题...从那以后我就对这个工具刮目相看了。

今天就跟大家好好聊聊这个Linux系统性能分析的瑞士军刀，保证让你看完就能上手实战。

sar到底是个什么东西

sar全称System Activity Reporter，翻译过来就是系统活动报告器。它属于sysstat工具包的一部分，可以收集、报告和保存系统活动信息。

简单点说，sar就像是给你的服务器装了个黑匣子，24小时不间断地记录着系统的各种性能指标。CPU使用率、内存占用、磁盘IO、网络流量...这些数据它都帮你记录下来，等你需要的时候随时调出来看。

最牛逼的地方在于，它不仅能实时监控，还能保存历史数据。你想看昨天凌晨3点服务器在干什么？没问题，sar帮你记着呢（有很多人是没有给服务器装监控的！！！）。

我记得有次遇到一个间歇性的性能问题，白天用户反馈系统卡，但是我们检查的时候又正常了。后来翻sar的历史记录，发现原来是每天下午2点有个定时任务在疯狂消耗CPU，问题瞬间就明朗了。

安装配置这些基础活儿

大部分Linux发行版都预装了sysstat包，如果没有的话安装也很简单：

CentOS/RHEL系统：

yum install sysstat
# 或者新版本用dnf
dnf install sysstat

Ubuntu/Debian系统：

apt-get install sysstat

装完之后需要启动服务：

systemctl enable sysstat
systemctl start sysstat

默认情况下，sar每10分钟收集一次数据，这个频率对大多数场景够用了。如果你想调整频率，可以编辑/etc/cron.d/sysstat文件。

比如想改成每5分钟收集一次：

*/5 * * * * root /usr/lib64/sa/sa1 1 1

数据文件默认保存在/var/log/sa/目录下，文件名格式是saDD（DD是日期）。比如今天是15号，那数据就保存在sa15文件里。

有个小坑要注意，sar的数据文件是二进制格式的，不能直接用cat或vi查看，必须通过sar命令来读取。

CPU监控 - 揪出那些偷懒的进程

先说CPU监控，这是sar最基础也是最常用的功能。

查看当前CPU使用情况：

sar -u 1 5

这条命令的意思是每1秒采样一次，总共采样5次。输出大概是这样的：

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使用率
• %nice: 运行在nice优先级下的用户态进程CPU使用率
• %system: 内核态CPU使用率
• %iowait: CPU等待IO操作的时间百分比
• %steal: 虚拟机环境下被其他虚拟机抢占的CPU时间
• %idle: CPU空闲时间百分比

我一般最关注这几个指标：%user高说明应用程序在拼命干活，%system高可能是系统调用太多或者内核有瓶颈，%iowait高就要检查磁盘IO了。

如果你的服务器是多核的（现在哪台服务器不是多核啊），可以用-P参数查看每个CPU核心的情况：

sar -u -P ALL 1 3

这样就能看出负载是否均衡分布在各个核心上了。我遇到过一些程序设计得不好，所有计算都跑在一个核心上，其他核心闲得发慌。

内存使用情况 - 找出内存杀手

内存监控用-r参数：

sar -r 1 5

输出类似这样：

03:30:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact
03:30:02 PM   1048576   3145728     75.00    102400    524288   2621440     62.50   1572864    786432

关键指标解释：

• kbmemfree: 空闲内存（KB）
• kbmemused: 已使用内存（KB）
• %memused: 内存使用率
• kbbuffers: 内核缓冲区使用的内存
• kbcached: 缓存使用的内存
• kbcommit: 已提交的内存
• %commit: 提交内存占总内存的百分比

这里有个常见误区，看到%memused很高就以为内存不够用了。其实Linux会把空闲内存用作缓存，真正需要关注的是当应用程序需要内存时，系统能否快速回收这些缓存。

我一般会结合swap使用情况一起看：

sar -S 1 5

如果swap使用率开始上升，那就真的需要考虑加内存了。

还有个很有用的参数-B，可以查看内存分页情况：

sar -B 1 5

输出中的pgpgin/s和pgpgout/s分别表示每秒从磁盘读取和写入的页面数。如果这两个值很高，说明系统在频繁地进行内存和磁盘之间的数据交换。

磁盘IO分析 - 硬盘也会累

磁盘IO监控是性能分析的重头戏，用-d参数：

sar -d 1 5

输出会列出每个磁盘设备的IO统计信息：

03:35:01 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
03:35:02 PM    dev8-0     15.84      0.00    253.47     16.00      0.02      1.25      0.63     10.00

重点关注这几个指标：

• tps: 每秒传输次数（IOPS）
• rd_sec/s: 每秒读取扇区数
• wr_sec/s: 每秒写入扇区数
• avgqu-sz: 平均队列长度
• await: 平均等待时间（毫秒）
• svctm: 平均服务时间（毫秒）
• %util: 磁盘利用率

%util这个指标特别重要，如果接近100%说明磁盘已经满负荷了。但这里有个陷阱，对于SSD来说，%util达到100%不一定意味着性能瓶颈，因为SSD可以并行处理多个IO请求。

await时间也很关键，如果这个值很高，用户就会感觉系统响应慢。我一般认为机械硬盘await超过20ms，SSD超过5ms就需要注意了。

想看具体某个分区的IO情况，可以这样：

sar -d -p 1 5

-p参数会显示分区名而不是设备名，这样看起来更直观。

网络流量监控 - 带宽用到哪了

网络监控用-n参数，这个参数后面可以跟不同的关键字：

查看网络接口流量：

sar -n DEV 1 5

输出类似：

03:40:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:40:02 PM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:40: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数
• rxcmp/s, txcmp/s: 每秒接收和发送的压缩包数

如果你想监控TCP连接状态：

sar -n TCP 1 5

这个命令会显示活跃连接数、新建连接数等信息，对于web服务器来说很有用。

还有个很有意思的参数SOCK：

sar -n SOCK 1 5

可以看到系统中各种类型socket的数量，包括TCP、UDP、RAW等。

有次我们的web服务突然变慢，用sar -n TCP一看，发现TIME_WAIT状态的连接数暴涨，原来是客户端没有正确复用连接导致的。

查看历史数据 - 时光倒流看问题

sar最强大的地方就是能查看历史数据。默认情况下，当天的数据保存在/var/log/sa/saDD文件中。

查看今天的CPU使用情况：

sar -u

查看昨天的：

sar -u -f /var/log/sa/sa14  # 假设昨天是14号

还可以指定时间范围：

sar -u -s 08:00:00 -e 18:00:00

这样就只看早上8点到晚上6点的数据了。

我经常用这个功能来分析问题的时间规律。比如用户反馈下午系统慢，我就会看看下午时段的各项指标，往往能很快定位到问题。

有个小技巧，如果你想生成一份漂亮的报告，可以把sar的输出重定向到文件：

sar -A -f /var/log/sa/sa15 > system_report_15.txt

-A参数表示输出所有统计信息，这样就得到了一份完整的系统性能报告。

实战案例 - 用sar解决真实问题

给大家分享几个我用sar解决问题的真实案例。

案例1：神秘的CPU占用

有次用户投诉系统在特定时间变慢，但我们监控显示CPU使用率不高。后来用sar -u查看历史数据，发现问题时段%iowait很高，说明CPU在等待IO。接着用sar -d查看磁盘，发现某个磁盘的await时间异常，最终定位到是备份脚本在高峰期运行导致的IO冲突。

案例2：内存泄漏追踪

应用程序运行一段时间后变慢，怀疑是内存泄漏。通过sar -r查看一周的内存使用趋势，发现kbmemused在持续增长，而且增长很规律。结合应用日志分析，找到了有问题的代码模块。

案例3：网络瓶颈定位

网站访问慢，初步排查CPU和磁盘都正常。用sar -n DEV发现网卡的txpck/s（发包率）接近理论上限，原来是遭到了小包攻击。通过调整网卡参数和防火墙规则解决了问题。

sar的进阶用法和小技巧

除了基本的监控功能，sar还有一些很实用的进阶技巧。

自定义输出格式

可以用-j参数将输出转换为JSON格式，方便程序处理：

sar -u -j 1 3

这个功能在写自动化脚本时特别有用。

监控特定进程

虽然sar本身不能监控单个进程，但可以结合其他工具。比如先用ps找到进程PID，然后用pidstat（也是sysstat包的一部分）：

pidstat -p 1234 1 5

数据文件管理

sar的数据文件会越来越大，需要定期清理。默认保存一个月，可以通过修改/etc/sysconfig/sysstat文件中的HISTORY参数来调整：

HISTORY=7  # 只保存7天

结合其他工具

sar输出的数据可以很方便地导入到Excel或者其他分析工具中。我经常把一周的数据导出来，用Excel做个图表，这样趋势就很明显了。

还可以写个简单的脚本，定期提取关键指标并发送邮件报告：

#!/bin/bash
echo "昨日系统性能摘要：" > /tmp/daily_report.txt
echo "CPU使用率：" >> /tmp/daily_report.txt
sar -u -f /var/log/sa/sa$(date -d yesterday +%d) | tail -1 >> /tmp/daily_report.txt
echo "内存使用率：" >> /tmp/daily_report.txt
sar -r -f /var/log/sa/sa$(date -d yesterday +%d) | tail -1 >> /tmp/daily_report.txt
mail -s "日报" admin@company.com < /tmp/daily_report.txt

常见问题和踩坑指南

用sar这么多年，也踩过不少坑，总结几个常见问题：

时区问题

sar显示的时间是系统本地时间，如果服务器时区设置不对，看历史数据时容易搞混。建议统一使用UTC时间。

数据文件损坏

偶尔会遇到sa文件损坏的情况，这时sar会报错。通常是因为系统异常关机导致的。这种情况下只能删除损坏的文件，没有好的恢复方法。

性能影响

虽然sar的开销很小，但在极高负载的系统上，频繁的数据收集还是可能产生影响。如果怀疑sar影响性能，可以临时停止sysstat服务测试一下。

磁盘空间

长期运行后，/var/log/sa/目录会占用不少空间。记得定期检查并清理旧文件。

和其他监控工具的对比

经常有人问我sar和top、htop、iostat这些工具有什么区别。

简单来说，top类工具适合实时查看当前状态，但不能保存历史数据。iostat专注于磁盘IO，功能比较单一。而sar是个综合性工具，既能实时监控，又能保存历史数据，还覆盖了系统的方方面面。

在我的日常工作中，通常是这样搭配使用：

• 发现问题时用top、htop快速查看当前状态
• 用sar分析历史趋势，找出问题规律
• 用专门的工具（如iotop、nethogs）深入分析具体问题

对于企业级监控，sar的数据还可以作为Zabbix、Nagios等监控系统的数据源，实现更复杂的监控和报警。

现在很多公司都在上云，云服务商通常提供自己的监控工具。但我觉得掌握sar这样的传统工具还是很有必要的，毕竟有些细节问题，还是要靠这些底层工具才能查得清楚。

总结

sar这个工具说复杂也复杂，说简单也简单。复杂在于它的参数很多，输出信息量大；简单在于掌握了几个核心用法，就能解决大部分问题。

我的建议是先从最基本的CPU（-u）、内存（-r）、磁盘（-d）、网络（-n DEV）监控开始，熟练了再去探索其他功能。最重要的是要结合实际问题去使用，纸上得来终觉浅，绝知此事要躬行。

记住，sar不只是个监控工具，更是个分析工具。它记录的不仅是数字，更是系统运行的轨迹。学会读懂这些轨迹，你就能像福尔摩斯一样从蛛丝马迹中找出问题的真相。

现在的系统越来越复杂，容器、微服务、云原生...新技术层出不穷。但无论技术怎么发展，底层的系统资源就那么几样：CPU、内存、磁盘、网络。掌握了sar，你就有了一把万能钥匙，能够打开性能问题的大门。

最后想说的是，工具只是手段，思路才是关键。sar能提供数据，但怎么分析这些数据，怎么从中找出问题，这需要经验的积累。希望这篇文章能帮你在sar的使用路上少走些弯路。

如果觉得这篇文章对你有帮助，记得点赞转发，也欢迎在评论区分享你使用sar的经验和遇到的问题。让我们一起在运维这条路上互相学习，共同成长！

关注@运维躬行录，我会持续分享更多实用的运维技术和实战经验，咱们下期见！

公众号：运维躬行录

个人博客：躬行笔记