Linux性能分析利器sar：从安装配置到实战排查全解

入行做运维那几年我最怕听到的一句话就是“服务器又卡了。”等你登录上去top、free、df挨个敲一遍机器却早恢复正常了——内存看着还好CPU也不高之前那波故障到底是怎么发生的只能靠猜。后来我把Linux下的sar用熟练了才真正觉得性能分析这事终于落地了。sar这工具最厉害的地方不是它能看到“此刻”的系统状态而是它能像行车记录仪一样把一段时间内的CPU、内存、磁盘、网络数据全部记录下来等故障发生后再回放现场。这篇文章没有废话直接从安装、配置、指标解读到实战排查把sar一次讲透。无论是刚接手Linux服务器的新人还是被线上故障折磨过几次的开发者这篇文章都能帮你省下大量瞎猜的时间。1. 为什么性能分析总是靠“猜”sar到底能帮我们做什么1.1 sar不是“又一个top”它解决的是瞬时数据的核心痛点很多人在服务器出问题时习惯敲top看到那一屏数据就以为掌握了全部。但top展示的是当前瞬间的快照一个进程跑完就看不到了网络流量峰值过了也查不到。生产环境里的故障往往不是“正在发生”而是“已经发生”等你看它的时候现场早没了。这种没有历史数据支撑的排查本质就是猜。sar是sysstat软件包里的系统活动报告工具。它的工作方式是在后台定期采集系统各项指标把结果写入二进制数据文件之后你随时可以用sar重新读取某一时间段的完整数据。我习惯把它理解成服务器的“黑匣子”平时默默工作不打扰你等需要复盘的时候它能把那段时间的一举一动都吐出来。更关键的是sar采集的指标范围非常全一条命令就能把系统运行的核心指标都覆盖掉。我的习惯是遇到性能问题先跑一条带时间范围的sar命令确认是CPU、内存、磁盘IO还是网络的问题再做针对性排查。借助这类linux常用命令组合十分钟之内基本能划定问题范围。1.2 sar到底能采集哪些数据——从CPU到网络的完整清单初学sar的人容易用错参数主要是不清楚它到底能看什么。梳理一下最常用的几类CPU使用率-u包括用户态、系统态、空闲、iowait等还能看每核情况。内存与交换分区-r看内存总量、空闲量、缓存、缓冲区以及交换分区使用情况。磁盘IO-b和-d前者看整体IO速率后者看每个磁盘设备的读写请求、平均等待时间等。网络流量-n DEV按网卡分别统计收发包数、字节数-n TCP能看TCP连接状态、重传率。进程队列与负载-q查看运行队列长度、平均负载、正在创建的任务数。其他还有inode、中断、电源管理等日常用得少但确实都有对应选项。这些选项记住一个规律sar后面跟的是你想看的子系统缩写再给时间间隔和次数比如sar -u 1 3就是每秒采样一次连续三次。用熟之后你完全可以把这些参数组合起来写进自己的日常巡检脚本里。1.3 先澄清一个常见误区这个sar跟遥感SAR、股票SAR没关系我每次写sar相关的文章评论区总有人问“你说的是合成孔径雷达那个SAR吗”或者“那是同花顺里的副图指标吧”。这里一次性说清楚Linux性能分析里的sar是sysstat包中的System Activity Reporter遥感领域经常提到的SAR是Synthetic Aperture Radar也就是合成孔径雷达成像技术而股票软件里的SAR指标是“抛物线转向指标”。三者只是缩写相同技术栈完全不同。网上搜索时如果搜“sar 图像识别”“光学和sar协同处理”看到的是遥感影像方向的内容跟本文没有任何关系。认准sysstat、/var/log/sa目录、sar -u这类关键词你找到的资料才对得上。这个误区好几个同事都踩过他们拿着遥感资料的术语去讨论服务器性能闹了不少笑话所以我专门说明一下。2. 半小时上手安装、启停、第一份性能报告2.1 安装sysstat三个主流发行版一条命令搞定使用sar的前提是装好sysstat工具包。很多最小化安装的Linux系统不会默认带这个包所以第一步是先确认。直接执行sar -V如果能输出版本号就说明已经装了。没装的话按发行版来Debian/Ubuntu系列apt install sysstatCentOS/RHEL系列yum install sysstat或用dnf install sysstatopenSUSE系列zypper install sysstat装完之后先别急着用手动执行一次systemctl start sysstat或service sysstat start把采集服务拉起来。这一步在Ubuntu上尤其容易忽略因为默认配置里采集开关没打开后面我会专门讲。另外提醒一点刚装完sysstat的前几分钟历史数据目录还是空的因为定时任务最早也要到下一个周期才会触发采集。想看历史数据要么等一个周期要么先用手动方式采集实时数据验证功能正常。2.2 两种采集模式手动前台采集与后台定时采集sar有两种工作方式理解清楚这个后面所有配置都不会乱。第一种是手动采样。比如sar -u 1 5表示每秒采样一次一共五次执行完直接输出结果然后退出。这种模式适合临时诊断“此刻”的系统状态比如登录服务器现场复现问题。缺点是你不盯着它数据就没有了。第二种是后台定时采集。sysstat装好后会通过systemd定时器或cron定期调起sadc这个采集程序把数据写进历史文件。这才是sar作为“黑匣子”的核心能力。实时采样是看现在定时采集是为了以后查看过去。我建议刚上手的人先把两种模式都跑一遍手动跑几条实时命令感受输出格式再确认后台服务是开启状态。两条腿走路排查问题时才不会出现“想看历史却没有数据”的尴尬。2.3 第一份报告怎么读从当前指标开始建立直觉看一个实际输出执行sar -u 1 3会得到类似这样三行Linux 5.15.0-91-generic (web-01) 01/15/2025 _x86_64_ (8 CPU) 14:30:01 CPU %user %nice %system %iowait %steal %idle 14:30:02 all 12.50 0.00 6.25 1.25 0.00 80.00 14:30:03 all 18.75 0.00 8.75 0.00 0.00 72.50 14:30:04 all 10.00 0.00 5.00 2.50 0.00 82.50 Average: all 13.75 0.00 6.67 1.25 0.00 78.33第一行是内核版本、主机名、日期、架构和CPU核数后面每一行是一次采样的结果。最关键的两列是%user用户态程序占用的CPU和%system内核态占用的CPU。如果你在上面跑Java应用、PHP进程%user高是正常的如果%system持续很高就要检查系统调用、中断是否异常。很多人一看%idle只有七八十就慌其实不对。空闲CPU说明还有余量真正要警惕的是%iowait长期偏高那说明CPU在等磁盘IO后面我会详细拆。3. 让sar成为“监控录像机”历史数据采集配置与落盘机制3.1 数据存在哪里sa文件与sadd文件的工作机制sar的历史数据文件默认放在两个地方。老一些的发行版放在/var/log/sa/新一些的放在/var/log/sysstat/。目录里你会看到两类文件saXX比如sa15是二进制数据文件存的是某个具体日期的所有采集数据日期就是文件名的数字。saXX注意后缀小写s开头的是saddYYYYMMDD它是文本文件用普通编辑器就能看方便人工排查。真正读取历史数据时用的命令形式是sar -f /var/log/sa/sa15。如果不指定-f参数sar默认读当天的历史文件。理解了这一点以后想翻哪天的数据就把文件名换成对应的日期即可。这套机制的好处是采集和数据读取分离。后台采集程序sadc负责写sar只负责读互不干扰。就算你正在用sar查看历史数据后台照样在继续采集完全不影响。3.2 定时任务与配置文件关键项定时采集不是自动就有的不同发行版机制不同但原理一样。以systemd环境为例sysstat安装后会生成sysstat-collect.timer这样一个定时器默认每10分钟触发一次sadc采集。你可以用systemctl status sysstat-collect.timer查看运行状态。要注意Ubuntu有个特殊习惯/etc/default/sysstat里的ENABLEDtrue必须设置默认是false也就是说装完包但没改这个配置的话后台根本不会采集。很多人在Ubuntu上用完sar说“没有历史数据”十有八九就是这个开关没打开。另外两个配置文件也要看一眼。一个是/etc/sysconfig/sysstat或/etc/default/sysstat里面有HISTORY参数默认是7表示保留最近7天的历史数据文件。另一个是关于sadc启动项的参数比如设置SADC_OPTIONS-S DISK可以额外采集块设备级别的详细数据建议显式加上否则-d选项可能没有历史数据可读。3.3 配置之后必须验证别等故障出现了才发现没采集配置完定时任务后我的习惯是当场合着日期去检查数据文件。执行ls -l /var/log/sa/如果能看到当天的sa文件并且文件大小不是0说明采集已经工作了。再顺手敲一条sar -f /var/log/sa/sa15如果提示不能打开文件多半是权限问题确认你是不是用root或者有权限的用户执行。还有一种情况是时区问题如果你在服务器上用date看到的日期和文件名的日期对不上读取也会失败。验证这一步别跳过。我踩过的坑很多有一次服务器出故障我自信满满去翻历史数据结果发现采集服务装完就没启动当天文件全是空的。所以我现在给所有新配置的机器都会做一次“采集验证”顺手写进交接文档避免后面的人重复踩坑。4. 核心指标逐个拆解CPU、内存、磁盘、网络的正确解读方式4.1 CPU指标不要只盯着%idle%iowait才是分流关键很多人看CPU就看空闲率这远远不够至少要把这几个指标分清楚。除了%user和%system还有一个容易忽略的%nice表示低优先级用户态进程占用的CPU。%steal在虚拟机上比较重要它表示宿主机抢占虚拟机CPU的时间比例如果持续偏高说明宿主机资源紧张再怎么优化虚拟机内部都没用。判断CPU瓶颈时%iowait是最容易误读的指标。它表示CPU等待磁盘IO完成而空闲的时间并不等于磁盘“忙”而是说CPU在等IO。举个例子如果%iowait到了30%同时磁盘队列很长说明磁盘IO是瓶颈如果%iowait很高但磁盘util并不高可能是程序频繁发起小IO真正的问题在应用侧优化方向完全不同。我的经验是先看整体再看每核。sar -P ALL 1 3可以看每个CPU核的使用情况。如果单核被打满而其他核空闲可能是典型的单线程应用瓶颈这时候要排查是不是Java里的某个线程全占了CPU。这些细节都是在实际故障中一点点摸出来的。4.2 内存与交换分区从kbcommit判断内存压力看内存执行sar -r 1 3输出里各项含义如下kbmemfree空闲物理内存。kbmemused已使用的物理内存。%memused使用百分比。kbbuffers和kbcached内核缓冲区和页缓存。kbcommit当前系统已承诺分配给进程的内存总量。%commitkbcommit占物理内存加交换分区总量的比例。很多新手看到%memused超过90%就紧张其实大部分是被kbcached占用的这种缓存内存可以随时释放给进程使用不算真正的内存压力。真正要看的是%commit这个值如果长期超过100%说明物理内存加上交换分区都不够用了系统会频繁触发OOM或交换。配合swapping指标看更清楚执行sar -W可以看到每秒换入换出页数。如果页面换入换出明显说明内存确实不够用程序可能在“打摆子”。另外内存问题的排查需要结合进程侧记录来判断。sar告诉你的是系统整体水位具体哪个进程吃内存多还得借助ps aux --sort-%mem这类linux常用命令进一步定位。4.3 磁盘与网络await、svctm、rxkB/s背后的门道磁盘相关的sar -b看汇总sar -d看每个设备的详细数据。常见字段有tps每秒IO请求数、rd_sec/s和wr_sec/s每秒读写扇区数、awaitIO请求平均等待时间单位毫秒、%util设备繁忙比例。这里最值得说的是await。它包含两部分请求在队列里排队的时间和实际处理的时间。如果await很高而%util不高可能是磁盘队列拥挤或设备本身慢如果%util已经接近100%说明磁盘接近饱和。可以用sar -x看扩展数据还能看到块大小、队列深度等信息配合wholesome判断。新版sysstat还有个变化旧的svctm字段默认不再输出官方理由是它不适合作为磁盘性能的直接衡量标准。如果你在网上看的教程还在教你解读svctm要注意版本差异避免被过时内容误导。网络方面sar -n DEV 1 3可以看到每个网卡的rxkB/s和txkB/s以及每秒收发包数。这个指标很好用线上流量异常升高时第一眼就能确认是不是网络被刷了。再配合sar -n TCP查看TCP重传率如果重传异常升高多半是网络质量或丢包问题。磁盘和网络的解读简单记一个原则先看有没有再看等多久最后看满没满。为了方便大家速查我整理了一个常用阈值参考表注意这些数值只适合做初步判断不同业务模型会有差异指标参考健康值预警信号说明%user视业务而定持续稳定在高位应用计算密集考虑扩容或优化%iowait5%10%且持续磁盘IO成为瓶颈的概率很大%steal0%10%虚拟机被宿主机“偷走”时间%commit80%100%内存承诺超限危险信号await10ms20ms持续磁盘响应变慢排队严重%util60%80%磁盘接近饱和需关注rxkB/s视带宽而定接近网卡上限可能被流量打满5. 实战排障用sar环环相扣定位一次线上CPU飙升5.1 故障现象与首轮确认先画时间线再动手有一次线上业务反馈说下午四点左右访问特别慢等我登录机器准备排查时系统已经恢复正常了。按老思路这时候只能求助监控平台看有没有更粗粒度的报表但那个平台数据粒度也不够。好在那台机器装了sysstat我直接用sar -u -f /var/log/sa/sa20 -s 15:30 -e 16:30把当天下午的CPU数据全部拉出来。注意这里-s和-e指定起止时间格式是HH:MM:SS。输出很清楚15:52之前CPU使用率都在20%以下从15:52开始猛地蹿到85%以上持续到16:15才回落。这就拿到了关键时间线。没有sar的话你只能对着一个莫名其妙的“已恢复”发呆现在至少知道故障持续了二十多分钟范围缩得很小了。顺便说一句用sar看历史数据时一定要明确日期和时间范围。服务数据保留有限越早排查越好。我的习惯是把故障时间段的关键数据先导出到文本文件存起来后面复盘、写报告都方便也防止数据被后续采集覆盖。5.2 从CPU曲线到进程定位sar加进程工具的交叉验证拿到时间线后下一步是确认这波CPU高负载是用户态还是系统态。继续看之前的输出%user占到了绝大部分%system很低判断是应用进程计算密集而不是内核出问题。再配合sar -n DEV看同一时间段的网络流量结果发现rxkB/s从正常的几十MB飙升到几百MB很快就猜到是某个对外服务接口被大量请求打中了。时间窗口确认后我再用ps aux --sort-%cpu直接查看当时的进程。虽然故障已经过去但进程还活着能看到它的累计CPU时间明显异常定位到具体的应用服务进程。这种“先历史后实时”的排查路径非常管用先通过sar锁定方向和时段再用进程工具确认对象不盲猜、不瞎找。如果你还需要更细的线程级信息可以把pidstat也装起来或者用top -H -p PID看线程。对于Java应用进一步抓取线程栈就能从cpu曲线一路追到具体代码行这是完整的证据链。5.3 事后复盘把历史数据交给证据链故障恢复后很多人觉得事情就结束了其实最有价值的复盘才刚刚开始。我会把当天的sa文件备份到专门目录以免被系统自动清理同时把sar -u、sar -n DEV的数据整理成图表标注出故障时间段放到故障报告里。还有一步很容易忽略核查采集链路本身。你这次能顺利还原故障是因为sysstat在正常采集。如果中间某个定时器停了可能就只有故障前和故障后的数据中间那段最重要的反而是空白。所以我每个月会随机抽一天检查sa文件是否完整配合systemctl status sysstat验证定时器健康。复盘过程中还有个细节就是确认服务器时区。如果机器是UTC时区而你按北京时间去匹配数据时间线会错位甚至得出完全相反的结论。我排查过一起类似问题最后发现是时区造成的乌龙。建议所有服务器统一用UTC业务展示层再转换时区这样底层日志的时间全部一致。6. 常见问题与避坑技巧那些文档里不写的细节6.1 高频报错排查速查表用sar遇到报错太正常了我把这几年碰到的典型问题整理成一个表报错信息常见原因处理办法command not found: sarsysstat未安装按发行版安装sysstatCannot open /var/log/sa/xx数据文件不存在或权限不足检查采集服务是否启动、用root执行sysstat-collect.timer not foundsystemd环境缺少定时器重装sysstat或检查软件包完整性数据文件size为0定时任务未触发或ENABLEDfalse修改/etc/default/sysstat启动服务时间范围超过文件覆盖范围保留历史天数不够调整HISTORY参数默认7天这些报错里最坑的是“文件存在但读不出来”一般是权限问题。数据文件权限默认是root普通用户读不了。建议给排查账号加sudo权限或者建立针对sa目录的只读授权而不是临时去改文件权限。6.2 容易踩坑的五个细节时区、sadc扩展、版本差异、数据保留与输出解析第一个坑是时区前面已经详细说过务必先看date再对数据文件名。第二个坑是SADC_OPTIONS。有些发行版默认不带-S DISK导致你用sar -d读历史数据时全是空的但读实时数据却有内容非常迷惑人。解决办法是在配置文件里显式加上这个参数然后重启sysstat采集服务。第三个坑是版本差异。sysstat 12之后svctm默认不输出有些字段名称也变了例如旧文档里的%memused在不同版本中位置相同但含义略有差别。建议先跑一个sar -V确认版本再去匹配对应的参数说明。第四个坑是历史数据保留。HISTORY7表示最多保留7天如果想长期存档需要另外做备份脚本把老文件挪到别的存储。我的做法是每次重大变更前后手动备份一次sa文件双保险。第五个坑是输出解析。sar输出里类似“Average”那行经常被脚本拿去取平均值。但注意平均是“你指定时间范围”的平均如果范围太大平均会掩盖瞬时尖峰。所以自动化告警时要同时看瞬时值和平均值别只看汇总行。6.3 我的日常使用习惯把sar用成顺手工具最后分享几个我坚持了很久的使用习惯。每天上班第一件事快速执行一个sar -f /var/log/sa/$(date %d -d yesterday) -s 00:00:00 -e 23:59:59 -q瞄一眼昨天整体负载曲线有没有异常波动。这比等用户报障要主动得多。排查具体问题时我喜欢把几个命令写成一串比如同时把CPU、内存、磁盘IO、网络流量四个指标导出来写进一个文件再统一分析。这样不会漏指标后续写报告也方便。命令大致是cd /tmp sar -u -f /var/log/sa/sa20 cpu.txt sar -r -f /var/log/sa/sa20 mem.txt sar -b -f /var/log/sa/sa20 io.txt sar -n DEV -f /var/log/sa/sa20 net.txt另外我至少要一个月做一次“采集链路体检”确认数据文件在持续更新定时器没掉磁盘空间也没被sa文件撑爆。这个习惯让我避免了好几次“要用数据时发现数据没了”的尴尬。从刚接触Linux时的“命令党”到后来靠数据做决策sar是转折点。它不能替你修故障但能让你修故障时不再靠猜。把这篇文章里提到的常用参数、历史文件机制、指标解读逻辑和排查路径练熟下次线上出问题你手里就有了一份非常硬核的“回放录像”。先戒掉瞎猜让数据说话。