这些年排查Linux服务器问题见得最多的一个场景就是有人跑过来喊“机器卡死了”然后啪地甩过来一张top截图。截图里load average一行三个数清一色几十甚至上百但你要问他这仨数到底说明什么多半支支吾吾说不清楚。这篇文章就把Linux负载查看和性能监控这条线彻底讲透从uptime的第一眼体检到vmstat、mpstat、iostat、sar这些命令的组合用法再到负载飙高之后的完整排查思路。内容偏实战适合刚接触Linux的运维新手也适合那些虽然会用命令但遇到问题还是没头绪的开发和老手。1. 为什么说load average是第一个该看的指标1.1 看懂那三个数字到底在说什么先说结论load average衡量的是系统处于可运行状态和不可中断睡眠状态的进程平均数量。很多人把它理解成CPU使用率这是错的。CPU使用率是高是低看的是一段时间内CPU忙碌的比例而负载看的是“排队”的长度。用生活里的场景类比一下。CPU就好比银行柜台进程就是来办业务的人。CPU使用率衡量的是柜台服务员忙不忙而负载衡量的是包括排队等待的人在内的总人数。如果柜台很忙但没人排队使用率可能是100%但负载并不高如果柜台不太忙但队伍排了老长说明系统调度出了问题负载就很高。uptime命令输出的三个数字是有讲究的$ uptime 14:32:10 up 12 days, 3:21, 2 users, load average: 0.08, 0.03, 0.01三个数分别是过去1分钟、5分钟、15分钟的平均负载。为什么要看三个而不是一个因为单看1分钟的数字容易误判比如你恰好赶上了一个定时任务的瞬间高峰1分钟负载冲到很高但5分钟和15分钟都很低这说明系统只是短暂波动不是真出问题了。反过来如果1分钟不高但15分钟持续走高说明负载是在慢慢累积的比如内存泄漏导致进程越来越多这种趋势比单点数值更值得警惕。1.2 负载多高算高不能拍脑袋很多人会背一个经验值负载不要超过CPU核数超过就说明有进程在排队。这个说法大方向对但细节上要分情况。先说结论对于Linux系统理想情况下load average应该低于CPU核数。如果是4核机器load在4以下说明CPU资源大致够用超过4说明开始有进程在排队等待CPU超过8那排队的人已经是CPU核数的两倍响应时间会明显变差。但这里有个很重要的坑不同Unix系统的负载计算方式不一样。Linux的负载统计包含了不可中断睡眠状态的进程也就是D状态进程而某些Unix系统不这么算。所以你在网上看到的老文章说“负载超过1就该报警”那是几十年前单核小型机时代的标准放在今天的多核服务器上完全不适用。判断负载是否正常的标准动作是这样的# 先看CPU核数 $ nproc 16 # 或 $ grep -c model name /proc/cpuinfo然后对照uptime的输出。16核机器负载长期在10以下都是正常的到12到15之间就该留意了超过16就说明CPU真的忙不过来了。还有一个反直觉的案例能说明问题曾经有个同事排查一台数据库服务器load average常年稳定在30以上但业务毫无感知。原因是这台机器是64核的负载30对应CPU利用率不到50%数据库查询依然很快。所以说一定要结合核数看负载脱离核数谈负载都是在耍流氓。1.3 load高不代表CPU忙这个误解会害死人前面说了Linux的负载包含D状态进程也就是不可中断睡眠。这种状态最常见的场景是进程正在等待磁盘IO。当一个进程发起磁盘读写时它进入D状态这段时间它不会让出CPU但这个进程本身并没有消耗CPU时间片。这就导致了一个经典现象机器负载飙到几十但top里一看CPU使用率只有个位数。很多新手在这一步就懵了以为是top命令坏了其实是负载统计口径的问题。负载高、CPU利用率低优先怀疑磁盘IO这是排查方向上的第一课。后面我会专门用一节来讲这种“CPU不忙但负载高”的排查思路这里先记住一个原则load average是个综合性指标CPU、磁盘、内存都能把它推高看到负载高的第一反应不应该是“CPU爆了”而是“系统里有东西堵住了”。2. 从uptime到top日常巡检的基本操作2.1 这几条命令的组合能解决80%的问题日常巡检不需要一上来就上perf这种重型工具绝大多数时候uptime加top加free加df就能定位问题方向。w命令比uptime多显示一些信息包括当前登录用户和他们在干什么。服务器出问题的时候w能快速帮你发现是不是有人登上来跑了什么野命令。$ w 14:32:10 up 12 days, 3:21, 2 users, load average: 0.08, 0.03, 0.01 USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.100 14:20 2.00s 0.05s 0.01s w root pts/1 192.168.1.101 09:15 1:02 0.10s 0.02s tail -f /var/log/nginx/access.logtop则是重头戏。这里不打算逐行讲只说几个最关键的判断点。top输出第一行的load average和uptime一致第二行是进程和线程总数第三行是CPU状态汇总第四行和第五行是内存和swap。真正干活的是下面那个进程列表默认按CPU使用率排序。按CPU排序的进程列表看得是当下瞬时的CPU占用。但瞬时值有迷惑性一个进程可能这0.1秒CPU跑到100%下一秒就休眠了。所以top用法里排第一位的技巧是按P键切换按CPU排序按M键切换按内存排序按T键切换按CPU时间累计排序。排查CPU问题我更倾向于按T看累计CPU时间因为一个进程如果累计CPU时间特别长说明它不是偶尔冒个尖而是长期在消耗CPU。2.2 top输出的CPU状态行信息量比你想的大top第三行长这样%Cpu(s): 12.5 us, 3.1 sy, 0.0 ni, 84.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st逐项拆解us用户态CPU时间占比跑应用程序消耗的sy内核态CPU时间占比系统调用、内核线程消耗的ni友好值调整过的进程消耗的CPU时间一般不多见id空闲CPU占比wa等待IO完成的时间占比这个值高说明磁盘或者网络IO有瓶颈hi处理硬件中断消耗的CPU时间si处理软件中断消耗的CPU时间网络数据包处理多了这个值会涨st被虚拟机管理程序偷走的时间云服务器上CPU竞争激烈的时候这个值会很高判断的逻辑很简单us高说明应用程序消耗CPU多可能是代码里有死循环或者计算密集任务sy高说明内核态消耗多系统调用频繁可能是小文件读写太碎、网络包太密集wa高说明在等IO磁盘大概率是瓶颈st高说明宿主机上邻居在抢资源。2.3 htop比top强在哪值不值得换htop是top的增强版彩色界面支持鼠标操作按F键可以排序按T键可以看树形进程关系。服务器上没装的话yum install htop或者apt install htop就能装。但我不建议所有场景都用htop替代top。原因有两个一是很多生产服务器是精简安装的出于安全考虑不希望装额外软件包二是自动化脚本里解析top的输出比解析htop的输出要方便得多。htop的价值主要在交互式排查尤其是按F6键可以按某个指标排序再配合F5的树形视图能快速理清进程间的父子关系。查僵尸进程或者找某个服务的子进程树时htop确实比top好使。top里还有个不常用但很有用的隐藏功能按1键可以展开或折叠每个CPU核心的使用情况。多核机器上如果只有个别核跑满说明负载不均衡可能和中断亲和性或者线程绑定有关。3. 负载排查的硬核三剑客vmstat、mpstat、pidstat3.1 vmstat不只会看内存它的负载视角更关键vmstat名字里带个vm让人以为它是看虚拟内存的实际上它是非常有用的系统性能概览工具。不加参数直接运行输出的是自开机以来的平均值这没太大参考价值正确用法是指定采样间隔和次数$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 836152 18244 7123836 0 0 12 57 8 12 3 1 96 0 0 1 0 0 835928 18244 7123888 0 0 0 20 15518 27116 12 4 84 0 0 3 0 0 835260 18244 7123904 0 0 0 0 16821 28931 14 5 81 0 0每1秒采样一次共采样5次。看哪里procs下面的r列代表运行队列中进程的数量也就是正在运行和等待CPU的进程数。这个数字如果长期大于CPU核数说明CPU不够用了。b列代表处于不可中断睡眠状态的进程数也就是在等IO的进程数这个数字持续大于0说明IO有瓶颈。swap下面的si和so分别代表换入和换出的内存页数。这两个数字只要不是0就说明物理内存不够用了系统在频繁地把内存数据换到磁盘上。这个过程非常消耗性能因为磁盘的速度比内存慢好几个数量级。io下面的bi和bo是块设备读入和写出的数据量单位是块。system下面的in是每秒中断次数cs是每秒上下文切换次数。上下文切换过高说明系统里有大量线程在频繁切换最常见的场景是线程数开太多每个线程都在抢CPU时间片。3.2 mpstat把CPU维度拆到每个核心mpstat是sysstat包里的工具主要用来按CPU核心维度看使用情况。$ mpstat -P ALL 1 3 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) 14:30:01 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 14:30:02 all 12.50 0.00 3.12 0.00 0.00 0.81 0.00 0.00 0.00 83.56 14:30:02 0 8.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 90.00 14:30:02 1 15.00 0.00 4.00 0.00 0.00 1.00 0.00 0.00 0.00 80.00-P ALL显示所有核心1表示间隔1秒3表示采样3次。日常排查的时候重点看有没有某一个或某几个核的%usr明显高于其他核。如果是说明有线程绑定在特定核心上运行或者中断没有均匀分散到所有核心。%soft这个指标值得单独拎出来讲。它代表软中断消耗的CPU时间。软中断密集的典型场景是网卡流量很大网络数据包的接收和处理主要靠软中断完成。如果%soft长期在10%以上说明网络收包已经成为系统瓶颈。3.3 pidstat锁定肇事进程vmstat和mpstat能看到系统总体情况但定位到具体进程还得靠pidstat。这个命令也在sysstat包里。$ pidstat -u 1 5 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) 14:32:01 UID PID %usr %system %guest %wait %CPU CPU Command 14:32:02 1000 1234 25.00 2.00 0.00 30.00 27.00 3 java 14:32:02 0 1456 5.00 1.00 0.00 10.00 6.00 7 mysqld和top看到的瞬时值不同pidstat输出的是采样周期内的平均值排除了瞬时抖动的干扰。%wait这一列代表进程等待运行的时间比例这个值高说明CPU不够分进程即便想跑也抢不到时间片。除了-u看CPUpidstat还有几个有用的参数-r看内存使用情况包括缺页异常次数-d看进程的IO读写情况-w看进程的上下文切换次数-p 指定PID只看某个特定进程排查上下文切换问题时pidstat -w很好用。输出里的cswch/s是自愿上下文切换次数nvcswch/s是非自愿上下文切换次数。非自愿切换次数高说明进程经常被系统强制抢占CPU通常是CPU资源紧缺的信号。4. 从瞬时到趋势sar是复盘性能问题的利器4.1 sar能告诉你昨天的机器发生了什么uptime、top这些命令有个共同的局限只能看当下。服务器出问题的时候你往往不在现场等你接到告警跑过去问题可能已经过去了。这时候就需要sar来事后复盘。sar是sysstat包的核心组件它后台有个定时任务会周期性采集系统性能数据并落盘。CentOS上默认采集间隔是10分钟一次数据保存在/var/log/sa/目录下。查看历史负载可以这样# 查看今天的系统性能历史 $ sar -q # 查看昨天的 $ sar -q -f /var/log/sa/sa$(date -d yesterday %d)-q选项输出的是负载相关的历史数据包括load average和运行队列长度。除了-qsar的各选项覆盖了系统性能的方方面面$ sar -u # CPU使用率历史 $ sar -r # 内存使用历史 $ sar -b # IO和传输速率历史 $ sar -n DEV # 网络设备吞吐历史 $ sar -n TCP # TCP连接状态历史 $ sar -S # swap空间使用历史遇到线上问题我的一般操作是先sar -q看负载是从什么时候开始涨的然后看同一时间段的sar -u、sar -r、sar -b把时间点对齐了对比分析基本就能还原出问题发生时的全貌。4.2 手动开启sysstat采集别等出事才后悔很多精简安装的服务器并没有启动sysstat的定时采集这意味着sar查不到历史数据只能实时采样。检查并开启采集的流程# 安装sysstat $ yum install -y sysstat # 或 apt install -y sysstat # 启动采集服务 $ systemctl enable sysstat $ systemctl start sysstat # 确认采集是否生效能看到定时任务就是OK的 $ cat /etc/cron.d/sysstatDeer新装的机器我会第一时间确认sysstat在跑。否则哪天凌晨3点出问题第二天早上想查数据发现什么都没留下来那种无力感太难受了。sysstat包里的sa1和sa2脚本是负责采集和汇总的/etc/cron.d/sysstat里定义了它们的执行计划。默认是每10分钟采一次对绝大多数场景够用了。如果机器IO压力特别大可以把间隔调短到5分钟甚至2分钟代价是历史数据文件会变大磁盘占用会多一些。4.3 用好sar的实时模式做对比sar的实时模式有时候比vmstat更好用因为它输出格式更规整方便截图记录。$ sar -u 1 5 $ sar -n DEV 1 3 $ sar -r 1 3排查过程中的操作习惯是先开一个top盯着进程列表再开一个sar -u 1 3记录CPU状态最后配合vmstat 1 3看队列和上下文切换。三个窗口同时跑哪个指标先异常就顺着哪条线查下去。这种方式比一个个命令轮着敲效率高很多。系统出问题的窗口期往往只有几分钟快速收集多维度数据是定位问题的前提。5. 内存和Swap的监控别等OOM才想起来5.1 free输出里的细节很多人看漏了free -h是查看内存使用最常用的命令但它的输出里有些细节容易被忽略。$ free -h total used free shared buff/cache available Mem: 15Gi 2.3Gi 6.1Gi 12Mi 7.1Gi 12Gi Swap: 2.0Gi 0B 2.0Gi重点看available这一列它才是系统真正可用的内存量。为什么不能直接看free列的6.1Gi因为buff/cache这部分内存在内存压力大的时候可以被回收复用。page cache是文件读写的缓存如果进程需要内存内核会优先释放page cache而不是直接把进程杀掉。buff和cache的区别也顺便说清楚。buff是块设备读写缓冲数据在写入块设备之前会先放到这里cache是文件系统页缓存读取过的文件内容会缓存在这里加速后续访问。两者本质都是内核为了提速而吃掉的内存都不是单纯的“已用”内存。判断内存是否紧张的指标不是used多不多而是available还有多少。如果available长期低于总内存的10%说明内存已经比较紧张了该考虑加内存或者优化应用的缓存策略了。5.2 swap用不用、用了多少linux真正的危险信号Linux系统在物理内存不够用的时候会把部分内存数据换到swap分区。这个过程本身就会带来严重的性能下降因为磁盘和内存的速度差距太大。很多年前的运维老经验是“swap一定要设”现在的大内存服务器上swap的争议一直存在。我的看法是重点不在于swap配多少而在于swap有没有被实际用到。vmstat输出里的si和so还有free输出里的Swap used都能反映swap使用情况。正常情况下这两个值应该是0。如果系统开始往swap里写数据说明物理内存已经告急。还有一个比swap使用量更早出现的信号free输出里available在持续下降同时cache在快速增长。这说明有进程在大量读取文件把page cache撑大了留给进程自己的内存越来越少最终可能触发OOM。5.3 追踪内存泄漏最简单的办法内存问题排查比CPU问题更麻烦因为内存是累积性的问题可能在几天甚至几周后才爆发。排查内存泄漏我习惯用pidstat -r定期采样统计进程的内存增长趋势。# 每10秒采样一次持续5分钟观察某个进程的RSS变化 $ pidstat -r -p 1234 10 30如果某个进程的RSS持续增长而且GC之后不回落基本可以断定有内存泄漏。Java进程要看堆内还是堆外C进程就要结合valgrind或者AddressSanitizer做更细的定位。另外提醒一句不要看到内存占用高就急着kill重启。有些应用有缓存预热的过程重启后进行第二次请求会变慢因为缓存都丢了。先判断是不是正常缓存行为再决定要不要重启。6. IO与网络负载高的隐形推手6.1 iostat帮你判断磁盘到底行不行排查磁盘性能iostat是最核心的命令。$ iostat -x 1 5 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util vda 3.20 1.80 45.20 18.40 0.00 0.00 0.00 0.00 0.80 2.50 0.01 14.12 10.22 1.10 0.55关键看几个指标%util设备繁忙程度。很多人以为%util到100%就是磁盘满负荷了这个理解不完全对。%util统计的是设备有IO请求的时间占比如果IO请求是持续不断地来%util就能到100%。但如果IO请求是突发式的中间有间歇%util不会到100%但设备能力可能已经见顶了r_await和w_await读和写的平均响应时间单位是毫秒。机械硬盘的响应时间在10ms左右算正常SSD在1ms左右算正常。如果r_await到了几百毫秒甚至上千毫秒磁盘基本就是快挂的状态aqu-sz平均队列长度。这个值高说明有大量IO请求在排队svctm平均服务时间。这个指标在新版iostat中已经不推荐使用了不用太在意排查思路是如果%util高、r_await正常说明磁盘确实在满负荷工作需要考虑扩容或者优化应用逻辑减少IO如果%util不高但r_await很高说明磁盘设备本身有问题可能是坏道、固件bug或者磁盘快挂了。6.2 用pidstat和iotop找出谁在疯狂读写磁盘定位到磁盘有问题后下一步就是找出到底是哪个进程在产生大量的IO。pidstat -d可以按进程维度看IO使用$ pidstat -d 1 5 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) 14:40:01 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 14:40:02 999 3210 128.00 5120.00 0.00 12 mysqld 14:40:02 0 5678 0.00 2048.00 0.00 0 rsyslogdkB_rd/s和kB_wr/s分别是每秒读写的KB数iodelay是进程等待IO完成的时间占比。MySQL进程疯狂写盘通常就是binlog刷盘、redo log刷盘或者有大事务在跑。更直观的工具是iotop它像top一样实时刷新按IO大小排序$ iotop -o-o选项只显示有IO操作的进程可以省去很多干扰项。iotop需要root权限运行因为要读取每个进程的IO统计信息普通用户跑不了。6.3 网络层面的负载别让软中断成为瓶颈网络流量大的服务器软中断softirq消耗的CPU可能比应用本身还多这也会推高系统负载。排查网络负载第一步是看实时流量$ sar -n DEV 1 5输出里的rxkB/s和txkB/s是每秒收发的KB数rxcmp/s是每秒收包数。关注点不在于流量绝对值大小而在于网卡是否已经接近满载。千兆网卡的极限大约是118MB/s万兆大约是1.1GB/s如果接近这个值网卡本身就是瓶颈。更细致的网络排查用nicstat这个工具在sysstat包里没有需要额外安装。它能显示网卡利用率、饱和度和丢包情况。如果确认是软中断导致CPU和负载偏高常见优化手段是启用RPSReceive Packet Steering让网卡中断均匀分布到多个CPU核心# 查看当前网卡队列的中断CPU亲和性 $ cat /proc/irq/$(cat /sys/class/net/eth0/device/irq)/smp_affinity_list启用RPS需要修改内核参数配合这个操作涉及面较广生产环境做之前一定要先了解清楚内核版本的差异不是所有版本都完美支持。7. 负载居高不下的几类场景复盘7.1 CPU密集型任务导致的负载飙升最直白的负载高场景就是CPU被跑满了。触发条件可能是业务高峰、定时任务重叠、或者代码里出现了死循环。这类问题的特征很明显vmstat的r列远大于CPU核数mpstat看到所有核心的%usr都很高pidstat能清晰看到肇事进程的CPU时间在持续增长。遇到过最典型的案例是电商大促零点那一秒大量用户同时下单应用服务器的线程池瞬间被打满所有核心CPU跑到100%。这种情况靠加机器能解决但更经济的方案是提前做限流和削峰。7.2 D状态进程堆积CPU闲着但负载爆炸回到开头说的那个反直觉问题负载高但CPU不高十有八九是D状态进程在堆积。案例复盘一台NFS客户端服务器业务跑得好好的突然负载从2飙到50。vmstat一看b列从0跳到了20多wa列从0涨到70%。top里排在最前面的进程都是D状态。后续排查发现是NFS服务端那边因为网络抖动导致客户端的所有IO请求卡住了。这种场景的处理思路是确认瓶颈在IO还是CPUvmstat看b列和wa列iostat -x看磁盘%util和r_await定位卡在哪个设备上iostat的Device列能看出是本地磁盘还是网络文件系统如果卡在NFS、Ceph这类网络存储上检查存储端的健康状态确认是偶发还是持续看sar -q的历史趋势有个经验很重要D状态进程是不能被kill掉的你执行kill -9也不会生效必须等IO请求超时回到用户态。所以在存储故障期间那些D状态进程会一直堆积在内存里甚至导致内存也跟着吃紧。7.3 内存不足触发OOM和swap颠簸内存不足导致的系统性能问题和CPU、磁盘的问题不太一样它的特征更加隐蔽。当物理内存即将耗尽时系统会做两件事一是把部分内存页换到swap二是启动OOM killer杀进程。swap的读写会带来额外的磁盘IO这会让vmstat里的si和so同时居高不下也会让wa异常升高。典型的现场是这样的free -h看到available所剩无几vmstat的si和so持续不为0dmesg里能看到OOM killer的日志一些进程莫名其妙消失了查OOM日志的方法$ dmesg | grep -i oom # 或者 $ journalctl -k | grep -i oomOOM日志里会列出被杀的进程PID和它的内存占用情况还记录了触发OOM时系统的内存使用状态。找到了被杀的进程顺藤摸瓜就能找到内存大户。7.4 不可中断IO和CPU排队同时出现怎么办有些故障场景是多指标同时异常的排查时要学会抓住主要矛盾。一次实际排查中一台机器负载30CPU使用率50%b列和r列同时都是10左右。这时要先搞清楚系统是从什么状态变成这样的如果是磁盘先出问题wa会先涨然后D状态进程堆积r列也跟着涨负载就这么叠加上去了。这种情况优先恢复磁盘健康CPU的排队问题会自行缓解。如果是CPU先被占满大量进程排队等待调度这会拖慢所有进程的进度包括那些执行IO的进程导致IO响应变慢、D状态进程变多。这种情况应该先处理CPU问题。判断依据可以看mpstat输出里的%iowait和%usr谁先达到高位也可以看排查期间的告警时间线。告警时间线对运维排查特别重要哪个指标先触发阈值往往问题就出在哪。8. 一次完整的线上负载排查实践复盘8.1 从告警到定位30分钟还原故障现场用一次完整的排查过程来收尾把前面讲的命令串起来。某个工作日上午10点监控告警应用服务器负载超过10持续5分钟。这是一台8核机器正常时负载在2到4之间10意味着CPU已经明显过载。第一步登录服务器跑uptime和vmstat 1 5$ uptime 10:05:32 up 3 days, 7:12, 3 users, load average: 12.35, 8.21, 5.43注意看趋势1分钟负载12.355分钟8.2115分钟5.43。负载正在快速上涨说明不是常态波动是突发问题。$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 9 0 0 41258 18244 3123836 0 0 12 157 208 412 72 5 23 0 0r列是9接近8核机器的临界值us列72%CPU使用已经很高。初步判断是CPU密集问题。第二步pidstat -u 1 5找出肇事进程$ pidstat -u 1 5 | awk $6 50 {print}某Java进程的%CPU在80以上还有几个Python进程各占30左右。Java进程是核心服务Python进程是定时爬虫任务。查了一下crontab发现10点正好是爬虫脚本和执行时间之前没有这个定时任务是最近加的。第三步确认方向后和业务方确认爬虫任务是临时的数据采集需求不属于核心链路。决定暂停该脚本负载在几分钟内回落到正常水平。这个案例没什么高深的地方但有两点值得记下来一是看负载要结合趋势1分钟、5分钟、15分钟三个数都在涨说明问题正在恶化二是定时任务叠加是负载飙升最常见的原因之一变更窗口要避开业务高峰。8.2 排障路上的常见错误和踩坑最后分享几个我踩过或见过的坑。第一个坑看到负载高就重启服务器。重启是最差的排障手段问题没有定位就直接重启下次照样出问题而且重启会丢失现场sysstat的历史数据还在但前后文信息少了。第二个坑把load average当成CPU使用率。前文反复强调过load高不一定是CPU问题也可能是D状态进程堆积。第三个坑只盯着一个指标看。CPU、内存、磁盘、网络是联动的一处出问题会牵连其他地方。用vmstat看整体用pidstat看进程用iostat看磁盘多维对照才能快速定位。第四个坑忘了看历史趋势。uptime和top只能看到当下真正的凶手往往在问题发生之前就潜伏了。定期用sar记录性能数据出问题时才有据可查。第五个坑生产环境乱装工具。有些排查命令需要编译安装没经过测试就装到生产环境万一影响现有运行环境就得不偿失。优先使用系统自带的命令sysstat这类常用包也应该通过正式渠道安装。我自己在平时的工作习惯是每台新上线的机器第一件事就是确保sysstat在运行装好vmstat、iostat、pidstat这些基础工具crontab里加一条性能数据归档的定时任务。这样出了事至少能往前翻数据而不是拍脑袋猜。这个习惯帮我省了很多通宵排查的时间也推荐你从现在开始就养成。
Linux负载查看与性能监控：从load average到vmstat、sar实战排查
这些年排查Linux服务器问题见得最多的一个场景就是有人跑过来喊“机器卡死了”然后啪地甩过来一张top截图。截图里load average一行三个数清一色几十甚至上百但你要问他这仨数到底说明什么多半支支吾吾说不清楚。这篇文章就把Linux负载查看和性能监控这条线彻底讲透从uptime的第一眼体检到vmstat、mpstat、iostat、sar这些命令的组合用法再到负载飙高之后的完整排查思路。内容偏实战适合刚接触Linux的运维新手也适合那些虽然会用命令但遇到问题还是没头绪的开发和老手。1. 为什么说load average是第一个该看的指标1.1 看懂那三个数字到底在说什么先说结论load average衡量的是系统处于可运行状态和不可中断睡眠状态的进程平均数量。很多人把它理解成CPU使用率这是错的。CPU使用率是高是低看的是一段时间内CPU忙碌的比例而负载看的是“排队”的长度。用生活里的场景类比一下。CPU就好比银行柜台进程就是来办业务的人。CPU使用率衡量的是柜台服务员忙不忙而负载衡量的是包括排队等待的人在内的总人数。如果柜台很忙但没人排队使用率可能是100%但负载并不高如果柜台不太忙但队伍排了老长说明系统调度出了问题负载就很高。uptime命令输出的三个数字是有讲究的$ uptime 14:32:10 up 12 days, 3:21, 2 users, load average: 0.08, 0.03, 0.01三个数分别是过去1分钟、5分钟、15分钟的平均负载。为什么要看三个而不是一个因为单看1分钟的数字容易误判比如你恰好赶上了一个定时任务的瞬间高峰1分钟负载冲到很高但5分钟和15分钟都很低这说明系统只是短暂波动不是真出问题了。反过来如果1分钟不高但15分钟持续走高说明负载是在慢慢累积的比如内存泄漏导致进程越来越多这种趋势比单点数值更值得警惕。1.2 负载多高算高不能拍脑袋很多人会背一个经验值负载不要超过CPU核数超过就说明有进程在排队。这个说法大方向对但细节上要分情况。先说结论对于Linux系统理想情况下load average应该低于CPU核数。如果是4核机器load在4以下说明CPU资源大致够用超过4说明开始有进程在排队等待CPU超过8那排队的人已经是CPU核数的两倍响应时间会明显变差。但这里有个很重要的坑不同Unix系统的负载计算方式不一样。Linux的负载统计包含了不可中断睡眠状态的进程也就是D状态进程而某些Unix系统不这么算。所以你在网上看到的老文章说“负载超过1就该报警”那是几十年前单核小型机时代的标准放在今天的多核服务器上完全不适用。判断负载是否正常的标准动作是这样的# 先看CPU核数 $ nproc 16 # 或 $ grep -c model name /proc/cpuinfo然后对照uptime的输出。16核机器负载长期在10以下都是正常的到12到15之间就该留意了超过16就说明CPU真的忙不过来了。还有一个反直觉的案例能说明问题曾经有个同事排查一台数据库服务器load average常年稳定在30以上但业务毫无感知。原因是这台机器是64核的负载30对应CPU利用率不到50%数据库查询依然很快。所以说一定要结合核数看负载脱离核数谈负载都是在耍流氓。1.3 load高不代表CPU忙这个误解会害死人前面说了Linux的负载包含D状态进程也就是不可中断睡眠。这种状态最常见的场景是进程正在等待磁盘IO。当一个进程发起磁盘读写时它进入D状态这段时间它不会让出CPU但这个进程本身并没有消耗CPU时间片。这就导致了一个经典现象机器负载飙到几十但top里一看CPU使用率只有个位数。很多新手在这一步就懵了以为是top命令坏了其实是负载统计口径的问题。负载高、CPU利用率低优先怀疑磁盘IO这是排查方向上的第一课。后面我会专门用一节来讲这种“CPU不忙但负载高”的排查思路这里先记住一个原则load average是个综合性指标CPU、磁盘、内存都能把它推高看到负载高的第一反应不应该是“CPU爆了”而是“系统里有东西堵住了”。2. 从uptime到top日常巡检的基本操作2.1 这几条命令的组合能解决80%的问题日常巡检不需要一上来就上perf这种重型工具绝大多数时候uptime加top加free加df就能定位问题方向。w命令比uptime多显示一些信息包括当前登录用户和他们在干什么。服务器出问题的时候w能快速帮你发现是不是有人登上来跑了什么野命令。$ w 14:32:10 up 12 days, 3:21, 2 users, load average: 0.08, 0.03, 0.01 USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.100 14:20 2.00s 0.05s 0.01s w root pts/1 192.168.1.101 09:15 1:02 0.10s 0.02s tail -f /var/log/nginx/access.logtop则是重头戏。这里不打算逐行讲只说几个最关键的判断点。top输出第一行的load average和uptime一致第二行是进程和线程总数第三行是CPU状态汇总第四行和第五行是内存和swap。真正干活的是下面那个进程列表默认按CPU使用率排序。按CPU排序的进程列表看得是当下瞬时的CPU占用。但瞬时值有迷惑性一个进程可能这0.1秒CPU跑到100%下一秒就休眠了。所以top用法里排第一位的技巧是按P键切换按CPU排序按M键切换按内存排序按T键切换按CPU时间累计排序。排查CPU问题我更倾向于按T看累计CPU时间因为一个进程如果累计CPU时间特别长说明它不是偶尔冒个尖而是长期在消耗CPU。2.2 top输出的CPU状态行信息量比你想的大top第三行长这样%Cpu(s): 12.5 us, 3.1 sy, 0.0 ni, 84.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st逐项拆解us用户态CPU时间占比跑应用程序消耗的sy内核态CPU时间占比系统调用、内核线程消耗的ni友好值调整过的进程消耗的CPU时间一般不多见id空闲CPU占比wa等待IO完成的时间占比这个值高说明磁盘或者网络IO有瓶颈hi处理硬件中断消耗的CPU时间si处理软件中断消耗的CPU时间网络数据包处理多了这个值会涨st被虚拟机管理程序偷走的时间云服务器上CPU竞争激烈的时候这个值会很高判断的逻辑很简单us高说明应用程序消耗CPU多可能是代码里有死循环或者计算密集任务sy高说明内核态消耗多系统调用频繁可能是小文件读写太碎、网络包太密集wa高说明在等IO磁盘大概率是瓶颈st高说明宿主机上邻居在抢资源。2.3 htop比top强在哪值不值得换htop是top的增强版彩色界面支持鼠标操作按F键可以排序按T键可以看树形进程关系。服务器上没装的话yum install htop或者apt install htop就能装。但我不建议所有场景都用htop替代top。原因有两个一是很多生产服务器是精简安装的出于安全考虑不希望装额外软件包二是自动化脚本里解析top的输出比解析htop的输出要方便得多。htop的价值主要在交互式排查尤其是按F6键可以按某个指标排序再配合F5的树形视图能快速理清进程间的父子关系。查僵尸进程或者找某个服务的子进程树时htop确实比top好使。top里还有个不常用但很有用的隐藏功能按1键可以展开或折叠每个CPU核心的使用情况。多核机器上如果只有个别核跑满说明负载不均衡可能和中断亲和性或者线程绑定有关。3. 负载排查的硬核三剑客vmstat、mpstat、pidstat3.1 vmstat不只会看内存它的负载视角更关键vmstat名字里带个vm让人以为它是看虚拟内存的实际上它是非常有用的系统性能概览工具。不加参数直接运行输出的是自开机以来的平均值这没太大参考价值正确用法是指定采样间隔和次数$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 836152 18244 7123836 0 0 12 57 8 12 3 1 96 0 0 1 0 0 835928 18244 7123888 0 0 0 20 15518 27116 12 4 84 0 0 3 0 0 835260 18244 7123904 0 0 0 0 16821 28931 14 5 81 0 0每1秒采样一次共采样5次。看哪里procs下面的r列代表运行队列中进程的数量也就是正在运行和等待CPU的进程数。这个数字如果长期大于CPU核数说明CPU不够用了。b列代表处于不可中断睡眠状态的进程数也就是在等IO的进程数这个数字持续大于0说明IO有瓶颈。swap下面的si和so分别代表换入和换出的内存页数。这两个数字只要不是0就说明物理内存不够用了系统在频繁地把内存数据换到磁盘上。这个过程非常消耗性能因为磁盘的速度比内存慢好几个数量级。io下面的bi和bo是块设备读入和写出的数据量单位是块。system下面的in是每秒中断次数cs是每秒上下文切换次数。上下文切换过高说明系统里有大量线程在频繁切换最常见的场景是线程数开太多每个线程都在抢CPU时间片。3.2 mpstat把CPU维度拆到每个核心mpstat是sysstat包里的工具主要用来按CPU核心维度看使用情况。$ mpstat -P ALL 1 3 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) 14:30:01 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 14:30:02 all 12.50 0.00 3.12 0.00 0.00 0.81 0.00 0.00 0.00 83.56 14:30:02 0 8.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 90.00 14:30:02 1 15.00 0.00 4.00 0.00 0.00 1.00 0.00 0.00 0.00 80.00-P ALL显示所有核心1表示间隔1秒3表示采样3次。日常排查的时候重点看有没有某一个或某几个核的%usr明显高于其他核。如果是说明有线程绑定在特定核心上运行或者中断没有均匀分散到所有核心。%soft这个指标值得单独拎出来讲。它代表软中断消耗的CPU时间。软中断密集的典型场景是网卡流量很大网络数据包的接收和处理主要靠软中断完成。如果%soft长期在10%以上说明网络收包已经成为系统瓶颈。3.3 pidstat锁定肇事进程vmstat和mpstat能看到系统总体情况但定位到具体进程还得靠pidstat。这个命令也在sysstat包里。$ pidstat -u 1 5 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) 14:32:01 UID PID %usr %system %guest %wait %CPU CPU Command 14:32:02 1000 1234 25.00 2.00 0.00 30.00 27.00 3 java 14:32:02 0 1456 5.00 1.00 0.00 10.00 6.00 7 mysqld和top看到的瞬时值不同pidstat输出的是采样周期内的平均值排除了瞬时抖动的干扰。%wait这一列代表进程等待运行的时间比例这个值高说明CPU不够分进程即便想跑也抢不到时间片。除了-u看CPUpidstat还有几个有用的参数-r看内存使用情况包括缺页异常次数-d看进程的IO读写情况-w看进程的上下文切换次数-p 指定PID只看某个特定进程排查上下文切换问题时pidstat -w很好用。输出里的cswch/s是自愿上下文切换次数nvcswch/s是非自愿上下文切换次数。非自愿切换次数高说明进程经常被系统强制抢占CPU通常是CPU资源紧缺的信号。4. 从瞬时到趋势sar是复盘性能问题的利器4.1 sar能告诉你昨天的机器发生了什么uptime、top这些命令有个共同的局限只能看当下。服务器出问题的时候你往往不在现场等你接到告警跑过去问题可能已经过去了。这时候就需要sar来事后复盘。sar是sysstat包的核心组件它后台有个定时任务会周期性采集系统性能数据并落盘。CentOS上默认采集间隔是10分钟一次数据保存在/var/log/sa/目录下。查看历史负载可以这样# 查看今天的系统性能历史 $ sar -q # 查看昨天的 $ sar -q -f /var/log/sa/sa$(date -d yesterday %d)-q选项输出的是负载相关的历史数据包括load average和运行队列长度。除了-qsar的各选项覆盖了系统性能的方方面面$ sar -u # CPU使用率历史 $ sar -r # 内存使用历史 $ sar -b # IO和传输速率历史 $ sar -n DEV # 网络设备吞吐历史 $ sar -n TCP # TCP连接状态历史 $ sar -S # swap空间使用历史遇到线上问题我的一般操作是先sar -q看负载是从什么时候开始涨的然后看同一时间段的sar -u、sar -r、sar -b把时间点对齐了对比分析基本就能还原出问题发生时的全貌。4.2 手动开启sysstat采集别等出事才后悔很多精简安装的服务器并没有启动sysstat的定时采集这意味着sar查不到历史数据只能实时采样。检查并开启采集的流程# 安装sysstat $ yum install -y sysstat # 或 apt install -y sysstat # 启动采集服务 $ systemctl enable sysstat $ systemctl start sysstat # 确认采集是否生效能看到定时任务就是OK的 $ cat /etc/cron.d/sysstatDeer新装的机器我会第一时间确认sysstat在跑。否则哪天凌晨3点出问题第二天早上想查数据发现什么都没留下来那种无力感太难受了。sysstat包里的sa1和sa2脚本是负责采集和汇总的/etc/cron.d/sysstat里定义了它们的执行计划。默认是每10分钟采一次对绝大多数场景够用了。如果机器IO压力特别大可以把间隔调短到5分钟甚至2分钟代价是历史数据文件会变大磁盘占用会多一些。4.3 用好sar的实时模式做对比sar的实时模式有时候比vmstat更好用因为它输出格式更规整方便截图记录。$ sar -u 1 5 $ sar -n DEV 1 3 $ sar -r 1 3排查过程中的操作习惯是先开一个top盯着进程列表再开一个sar -u 1 3记录CPU状态最后配合vmstat 1 3看队列和上下文切换。三个窗口同时跑哪个指标先异常就顺着哪条线查下去。这种方式比一个个命令轮着敲效率高很多。系统出问题的窗口期往往只有几分钟快速收集多维度数据是定位问题的前提。5. 内存和Swap的监控别等OOM才想起来5.1 free输出里的细节很多人看漏了free -h是查看内存使用最常用的命令但它的输出里有些细节容易被忽略。$ free -h total used free shared buff/cache available Mem: 15Gi 2.3Gi 6.1Gi 12Mi 7.1Gi 12Gi Swap: 2.0Gi 0B 2.0Gi重点看available这一列它才是系统真正可用的内存量。为什么不能直接看free列的6.1Gi因为buff/cache这部分内存在内存压力大的时候可以被回收复用。page cache是文件读写的缓存如果进程需要内存内核会优先释放page cache而不是直接把进程杀掉。buff和cache的区别也顺便说清楚。buff是块设备读写缓冲数据在写入块设备之前会先放到这里cache是文件系统页缓存读取过的文件内容会缓存在这里加速后续访问。两者本质都是内核为了提速而吃掉的内存都不是单纯的“已用”内存。判断内存是否紧张的指标不是used多不多而是available还有多少。如果available长期低于总内存的10%说明内存已经比较紧张了该考虑加内存或者优化应用的缓存策略了。5.2 swap用不用、用了多少linux真正的危险信号Linux系统在物理内存不够用的时候会把部分内存数据换到swap分区。这个过程本身就会带来严重的性能下降因为磁盘和内存的速度差距太大。很多年前的运维老经验是“swap一定要设”现在的大内存服务器上swap的争议一直存在。我的看法是重点不在于swap配多少而在于swap有没有被实际用到。vmstat输出里的si和so还有free输出里的Swap used都能反映swap使用情况。正常情况下这两个值应该是0。如果系统开始往swap里写数据说明物理内存已经告急。还有一个比swap使用量更早出现的信号free输出里available在持续下降同时cache在快速增长。这说明有进程在大量读取文件把page cache撑大了留给进程自己的内存越来越少最终可能触发OOM。5.3 追踪内存泄漏最简单的办法内存问题排查比CPU问题更麻烦因为内存是累积性的问题可能在几天甚至几周后才爆发。排查内存泄漏我习惯用pidstat -r定期采样统计进程的内存增长趋势。# 每10秒采样一次持续5分钟观察某个进程的RSS变化 $ pidstat -r -p 1234 10 30如果某个进程的RSS持续增长而且GC之后不回落基本可以断定有内存泄漏。Java进程要看堆内还是堆外C进程就要结合valgrind或者AddressSanitizer做更细的定位。另外提醒一句不要看到内存占用高就急着kill重启。有些应用有缓存预热的过程重启后进行第二次请求会变慢因为缓存都丢了。先判断是不是正常缓存行为再决定要不要重启。6. IO与网络负载高的隐形推手6.1 iostat帮你判断磁盘到底行不行排查磁盘性能iostat是最核心的命令。$ iostat -x 1 5 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util vda 3.20 1.80 45.20 18.40 0.00 0.00 0.00 0.00 0.80 2.50 0.01 14.12 10.22 1.10 0.55关键看几个指标%util设备繁忙程度。很多人以为%util到100%就是磁盘满负荷了这个理解不完全对。%util统计的是设备有IO请求的时间占比如果IO请求是持续不断地来%util就能到100%。但如果IO请求是突发式的中间有间歇%util不会到100%但设备能力可能已经见顶了r_await和w_await读和写的平均响应时间单位是毫秒。机械硬盘的响应时间在10ms左右算正常SSD在1ms左右算正常。如果r_await到了几百毫秒甚至上千毫秒磁盘基本就是快挂的状态aqu-sz平均队列长度。这个值高说明有大量IO请求在排队svctm平均服务时间。这个指标在新版iostat中已经不推荐使用了不用太在意排查思路是如果%util高、r_await正常说明磁盘确实在满负荷工作需要考虑扩容或者优化应用逻辑减少IO如果%util不高但r_await很高说明磁盘设备本身有问题可能是坏道、固件bug或者磁盘快挂了。6.2 用pidstat和iotop找出谁在疯狂读写磁盘定位到磁盘有问题后下一步就是找出到底是哪个进程在产生大量的IO。pidstat -d可以按进程维度看IO使用$ pidstat -d 1 5 Linux 5.4.0-26-generic (hostname) 2025-01-15 _x86_64_ (16 CPU) 14:40:01 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 14:40:02 999 3210 128.00 5120.00 0.00 12 mysqld 14:40:02 0 5678 0.00 2048.00 0.00 0 rsyslogdkB_rd/s和kB_wr/s分别是每秒读写的KB数iodelay是进程等待IO完成的时间占比。MySQL进程疯狂写盘通常就是binlog刷盘、redo log刷盘或者有大事务在跑。更直观的工具是iotop它像top一样实时刷新按IO大小排序$ iotop -o-o选项只显示有IO操作的进程可以省去很多干扰项。iotop需要root权限运行因为要读取每个进程的IO统计信息普通用户跑不了。6.3 网络层面的负载别让软中断成为瓶颈网络流量大的服务器软中断softirq消耗的CPU可能比应用本身还多这也会推高系统负载。排查网络负载第一步是看实时流量$ sar -n DEV 1 5输出里的rxkB/s和txkB/s是每秒收发的KB数rxcmp/s是每秒收包数。关注点不在于流量绝对值大小而在于网卡是否已经接近满载。千兆网卡的极限大约是118MB/s万兆大约是1.1GB/s如果接近这个值网卡本身就是瓶颈。更细致的网络排查用nicstat这个工具在sysstat包里没有需要额外安装。它能显示网卡利用率、饱和度和丢包情况。如果确认是软中断导致CPU和负载偏高常见优化手段是启用RPSReceive Packet Steering让网卡中断均匀分布到多个CPU核心# 查看当前网卡队列的中断CPU亲和性 $ cat /proc/irq/$(cat /sys/class/net/eth0/device/irq)/smp_affinity_list启用RPS需要修改内核参数配合这个操作涉及面较广生产环境做之前一定要先了解清楚内核版本的差异不是所有版本都完美支持。7. 负载居高不下的几类场景复盘7.1 CPU密集型任务导致的负载飙升最直白的负载高场景就是CPU被跑满了。触发条件可能是业务高峰、定时任务重叠、或者代码里出现了死循环。这类问题的特征很明显vmstat的r列远大于CPU核数mpstat看到所有核心的%usr都很高pidstat能清晰看到肇事进程的CPU时间在持续增长。遇到过最典型的案例是电商大促零点那一秒大量用户同时下单应用服务器的线程池瞬间被打满所有核心CPU跑到100%。这种情况靠加机器能解决但更经济的方案是提前做限流和削峰。7.2 D状态进程堆积CPU闲着但负载爆炸回到开头说的那个反直觉问题负载高但CPU不高十有八九是D状态进程在堆积。案例复盘一台NFS客户端服务器业务跑得好好的突然负载从2飙到50。vmstat一看b列从0跳到了20多wa列从0涨到70%。top里排在最前面的进程都是D状态。后续排查发现是NFS服务端那边因为网络抖动导致客户端的所有IO请求卡住了。这种场景的处理思路是确认瓶颈在IO还是CPUvmstat看b列和wa列iostat -x看磁盘%util和r_await定位卡在哪个设备上iostat的Device列能看出是本地磁盘还是网络文件系统如果卡在NFS、Ceph这类网络存储上检查存储端的健康状态确认是偶发还是持续看sar -q的历史趋势有个经验很重要D状态进程是不能被kill掉的你执行kill -9也不会生效必须等IO请求超时回到用户态。所以在存储故障期间那些D状态进程会一直堆积在内存里甚至导致内存也跟着吃紧。7.3 内存不足触发OOM和swap颠簸内存不足导致的系统性能问题和CPU、磁盘的问题不太一样它的特征更加隐蔽。当物理内存即将耗尽时系统会做两件事一是把部分内存页换到swap二是启动OOM killer杀进程。swap的读写会带来额外的磁盘IO这会让vmstat里的si和so同时居高不下也会让wa异常升高。典型的现场是这样的free -h看到available所剩无几vmstat的si和so持续不为0dmesg里能看到OOM killer的日志一些进程莫名其妙消失了查OOM日志的方法$ dmesg | grep -i oom # 或者 $ journalctl -k | grep -i oomOOM日志里会列出被杀的进程PID和它的内存占用情况还记录了触发OOM时系统的内存使用状态。找到了被杀的进程顺藤摸瓜就能找到内存大户。7.4 不可中断IO和CPU排队同时出现怎么办有些故障场景是多指标同时异常的排查时要学会抓住主要矛盾。一次实际排查中一台机器负载30CPU使用率50%b列和r列同时都是10左右。这时要先搞清楚系统是从什么状态变成这样的如果是磁盘先出问题wa会先涨然后D状态进程堆积r列也跟着涨负载就这么叠加上去了。这种情况优先恢复磁盘健康CPU的排队问题会自行缓解。如果是CPU先被占满大量进程排队等待调度这会拖慢所有进程的进度包括那些执行IO的进程导致IO响应变慢、D状态进程变多。这种情况应该先处理CPU问题。判断依据可以看mpstat输出里的%iowait和%usr谁先达到高位也可以看排查期间的告警时间线。告警时间线对运维排查特别重要哪个指标先触发阈值往往问题就出在哪。8. 一次完整的线上负载排查实践复盘8.1 从告警到定位30分钟还原故障现场用一次完整的排查过程来收尾把前面讲的命令串起来。某个工作日上午10点监控告警应用服务器负载超过10持续5分钟。这是一台8核机器正常时负载在2到4之间10意味着CPU已经明显过载。第一步登录服务器跑uptime和vmstat 1 5$ uptime 10:05:32 up 3 days, 7:12, 3 users, load average: 12.35, 8.21, 5.43注意看趋势1分钟负载12.355分钟8.2115分钟5.43。负载正在快速上涨说明不是常态波动是突发问题。$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 9 0 0 41258 18244 3123836 0 0 12 157 208 412 72 5 23 0 0r列是9接近8核机器的临界值us列72%CPU使用已经很高。初步判断是CPU密集问题。第二步pidstat -u 1 5找出肇事进程$ pidstat -u 1 5 | awk $6 50 {print}某Java进程的%CPU在80以上还有几个Python进程各占30左右。Java进程是核心服务Python进程是定时爬虫任务。查了一下crontab发现10点正好是爬虫脚本和执行时间之前没有这个定时任务是最近加的。第三步确认方向后和业务方确认爬虫任务是临时的数据采集需求不属于核心链路。决定暂停该脚本负载在几分钟内回落到正常水平。这个案例没什么高深的地方但有两点值得记下来一是看负载要结合趋势1分钟、5分钟、15分钟三个数都在涨说明问题正在恶化二是定时任务叠加是负载飙升最常见的原因之一变更窗口要避开业务高峰。8.2 排障路上的常见错误和踩坑最后分享几个我踩过或见过的坑。第一个坑看到负载高就重启服务器。重启是最差的排障手段问题没有定位就直接重启下次照样出问题而且重启会丢失现场sysstat的历史数据还在但前后文信息少了。第二个坑把load average当成CPU使用率。前文反复强调过load高不一定是CPU问题也可能是D状态进程堆积。第三个坑只盯着一个指标看。CPU、内存、磁盘、网络是联动的一处出问题会牵连其他地方。用vmstat看整体用pidstat看进程用iostat看磁盘多维对照才能快速定位。第四个坑忘了看历史趋势。uptime和top只能看到当下真正的凶手往往在问题发生之前就潜伏了。定期用sar记录性能数据出问题时才有据可查。第五个坑生产环境乱装工具。有些排查命令需要编译安装没经过测试就装到生产环境万一影响现有运行环境就得不偿失。优先使用系统自带的命令sysstat这类常用包也应该通过正式渠道安装。我自己在平时的工作习惯是每台新上线的机器第一件事就是确保sysstat在运行装好vmstat、iostat、pidstat这些基础工具crontab里加一条性能数据归档的定时任务。这样出了事至少能往前翻数据而不是拍脑袋猜。这个习惯帮我省了很多通宵排查的时间也推荐你从现在开始就养成。
