服务器CPU报警或者负载飙高的时候，大多数人第一个动作就是敲top。我自己也一样，不管现在有多少花里胡哨的监控平台，遇到性能问题第一反应还是top——它快、轻、哪台机器都有，不需要装任何东西。但top这个命令有个尴尬的地方：信息密度太高了。第一次接触的人看到满屏数字根本不知道该看哪儿，干了好几年运维的人也可能没真正搞懂首部那几行百分比在说什么。这篇文章不准备讲太深的内核原理，就聚焦一件事：当你面对一台Linux服务器，怎样用top快速判断它是不是真的有问题、问题大概率出在哪个进程，以及怎样把top从一次性的手工排查变成可以落盘的持续监控。
无论你是刚入行的运维、经常要上服务器看日志的后端开发，还是准备面试时被问到“怎么排查CPU飙高”的求职者，这都算是一份能直接照着用的操作路径。
1. 先分清两种用法：交互式的“看”和批处理式的“采”
很多人用top就只会敲一下回车，然后盯着屏幕看刷新。这其实只发挥了它一半的能力。top从设计上就分两种工作模式：一种是默认的交互式全屏模式，适合人坐在终端前实时观察；另一种是批处理模式，通过参数直接输出文本结果，适合脚本采集和落盘。搞清楚这两种模式，是高效使用top的第一步。
1.1 交互模式适合人工诊断，批处理模式适合脚本采集
交互模式就是你直接在终端里执行top，屏幕上会持续刷新，并且支持各种快捷键操作。这种模式的优点是反馈快，适合线上出问题时登录上去手动看，一边观察数值变化一边按P按M切换排序，快速锁定可疑进程。缺点是输出不稳定，每次刷新都会重绘屏幕，所以不适合把结果重定向到文件里——你拿到的会是带各种转义控制符的一堆乱码。
批处理模式是top -b，输出不会清屏重绘，而是像普通命令一样一帧一帧打印出来。这个模式通常配合-n指定采样次数使用，比如top -b -n 1表示只输出一次当前状态。批处理模式的价值在于它把top变成了一个可以被脚本调用的数据采集工具，后面第4部分会专门展开讲。一句话总结：人看用交互模式，机器采数据用批处理模式，别混着用。
1.2 上手前先搞懂那几个默认参数
top默认每3秒刷新一次，这个间隔由-d参数控制。很多人不知道的是，这个间隔在批处理模式里同样生效，后面做定时采样时会牵扯到执行时长的计算。除此之外，有几个参数我几乎天天用：
-p指定PID，只监控某个进程，比如top -p 12345。-u按用户名过滤，只看某个用户的进程，比如top -u nginx。-H切换到线程视图，显示进程下的每个线程，排查多线程应用卡死时非常关键。-d设置刷新间隔，单位是秒，也可以传小数，比如-d 0.5就是每0.5秒刷一次。
还有一个容易被忽略但很重要的参数是-i，它会让top隐藏空闲进程。生产环境上几百个进程里大部分都在sleep，不加-i的话你根本看不清谁在真正吃CPU，所以我个人的习惯是top -i常驻，只显示非空闲的进程。
1.3 我平时看top的顺序：先看负载，再看CPU，最后定位进程
敲下top之后，不要一上来就盯着进程列表找谁CPU高，而是按“全局→子系统→进程”的顺序来。先看右上角的load average，判断系统整体是不是繁忙；再看第二行和第三行的进程数与CPU状态百分比，判断是CPU计算密集、IO等待还是进程堆积；最后才看进程列表，用P按CPU排序、M按内存排序，具体是哪个进程在作妖。
为什么顺序很重要？因为同一个现象背后可能是完全不同的原因。比如load average很高但CPU的id也很高，说明CPU大量时间在空转，这时候问题大概率出在磁盘IO或者不可中断睡眠上，你去进程列表里找高CPU进程是徒劳的。我见过不少人一上来就按P，看到一个进程500%就急着kill，结果load还是没降，因为真正的瓶颈根本不在CPU。养成从上到下看的习惯，会少走很多弯路。
2. 读懂首部数据：负载、CPU状态和内存的关联判断
top输出的首部是整块信息里最浓缩也最容易误读的部分。很多教程只会告诉你每个字段的字面含义，但实际排障的时候，这些字段必须放在一起看才有意义。负载高不高要和CPU核数挂钩，CPU忙不忙要区分用户态和内核态，内存够不够要看缓存和交换分区的联动。
2.1 load average三个数字背后的排队逻辑
先看load average，后面跟着三个数字，分别代表过去1分钟、5分钟、15分钟的平均负载。很多人把负载和CPU使用率画等号，这是最常见的误解。负载的本质是“运行队列长度”的滑动平均值，它统计了两类进程的数量：一类是正在CPU上运行的，另一类是准备好运行但没抢到CPU时间片的，在Linux里还额外包含处于不可中断睡眠状态（D状态）的进程。
因为负载和CPU核数直接相关，所以判断负载是否过高的标准是“每个核平均承担多少负载”。4核机器负载到4，相当于每个核都被占满；8核机器负载到4，说明还有一半算力闲着。有个粗略的经验值：负载持久超过核数，系统就已经过载了；超过核数一半，就该关注趋势了。另外，因为Linux把不可中断睡眠也算进负载，所以当大量线程卡在磁盘IO等待上时，负载会虚高，而CPU使用率反而不高。这个现象在排查数据库或文件服务性能问题时特别常见。
2.2 %Cpu(s)那一行才是CPU瓶颈的关键
%Cpu(s)这一行包含us、sy、ni、id、wa、hi、si、st几个字段。逐个解释没什么意思，我更习惯把它们分成三组来看：
us（用户态）+sy（内核态）是真正干活的CPU时间。如果us很高，说明大量用户态进程在计算；如果sy很高，说明系统调用来回切换、内核处理占了太多开销，常见于频繁读写、频繁创建线程的场景。id是空闲率，但它是扣除wa之后才剩下的空闲，所以id高不代表没问题。
wa代表CPU等待IO完成的时间占比。这个值一旦持续偏高，基本可以断定瓶颈在存储层——磁盘太慢、IO队列太长、或者NFS网络存储抖动。很多新手容易混淆的一点是，wa高的时候CPU并没有闲着，它只是把时间片都耗在了等IO上。
st是steal time，主要在虚拟化环境里出现，表示CPU时间被宿主机偷走分给其他虚拟机了。你在云服务器上看到st很高，说明同物理机上的邻居在跟你抢资源，这种情况靠优化自己机器基本无解，要么换实例规格，要么错峰。
2.3 内存行和Swap行怎么结合看
内存部分的Mem行显示total、free、used、buff/cache。这里有一个Linux内存管理的特点容易误导人：系统会把空闲内存大量用作page cache，也就是buff/cache部分，这部分内存看起来是“被用了”，但实际上只要有进程申请内存，内核会随时回收它。所以判断内存够不够，不能只看free那一列，更合理的口径是free + buff/cache减去不可回收部分才是当前可用的近似值。
Swap行如果显示used比较高，说明物理内存曾经不够用过，系统把部分内存页换到了磁盘。swap的使用情况需要结合free里的available字段来看。现代Linux里available是一个比较靠谱的“真实可用内存”估算值，它包含可回收的缓存，比单纯看free准确得多。如果你发现swap used持续增长，同时available不断走低，那内存压力确实在累积，光清缓存没用，得考虑扩容或优化进程内存占用。
3. 进程列表的字段与交互操作：快速定位元凶
首部数据看完了，接下来的重头戏是进程列表。怎样在几十上百个进程里快速把问题揪出来，靠的是两件事：一是认得每个字段的准确含义，二是熟练使用交互快捷键。这两件事都不难，但缺一不可。
3.1 进程行里最值得盯的几个字段
进程列表的字段很多，但日常排障我基本只看这么几个：PID、USER、%CPU、%MEM、RES、S、TIME+、COMMAND。
RES是进程实际占用的物理内存，单位是KB，这个字段比VIRT更能反映真实内存消耗。VIRT显示的是进程虚拟地址空间大小，它包含共享库、代码段、映射文件等大量并不真正占物理内存的部分，所以经常是几GB都不稀奇，很多教程喜欢拿VIRT吓唬人，实际没意义。判断进程内存泄漏时，盯RES就够了。
%CPU是进程对单核CPU的占用百分比，多核情况下可以超过100%。比如4核机器上一个进程跑满两个核，%CPU会显示200%左右。%MEM是进程占用物理内存占总内存的百分比。如果要找内存大户，按M按这个字段排序就行。
S是进程状态，常见的有R（运行中）、S（可中断睡眠）、D（不可中断睡眠）、Z（僵尸）、T（停止）。其中D状态说明进程卡在内核态IO等待，通常配合wa高一起出现；Z状态则说明子进程已退出但父进程没有回收它。这两种状态的排查方向完全不同，后面单独说。
3.2 常用的排序和过滤快捷键
top的交互快捷键是真正提高效率的地方，下面这些我基本每次都会用到：
P：按CPU使用率降序排列，找谁在吃CPU最快。M：按内存占用降序排列，排查内存问题首选。T：按累计CPU时间排序，可以找出长期占用CPU的“慢性子”进程。N：按PID排序，方便按启动先后找到新起的进程。R：反转当前排序方向。u：输入用户名，只看这个用户的进程。k：输入PID和信号值，直接给进程发信号，默认是15（SIGTERM）。r：重新设置进程的nice值，调整优先级。1：展开/折叠多核CPU的每个核心状态行，看是不是某个核被打满。W：把当前配置保存到~/.toprc，下次启动自动生效。
还有一个容易被忽视的快捷键是c，它可以在完整命令行和进程名之间切换。默认显示进程名，很多场景下看不出这个进程的具体身份，按一下c看完整路径，能避免误判。另外，按f可以进入字段管理界面，用空格键勾选要显示的字段，按q保存退出，灵活定制适合自己场景的列。
3.3 进程状态里的D和Z，代表两种完全不同的问题
看到D状态进程，说明有线程在做不可中断的同步IO操作，比如读取磁盘、访问NFS。D状态本身说明不了是“坏进程”，它只是告诉我们这个进程在等待IO返回。如果大量进程同时陷入D状态，同时wa飙高，基本可以判断存储子系统出现瓶颈，建议用iostat或iotop进一步确认是哪块盘或哪个挂载点在拖累。
看到Z状态进程，俗称僵尸进程，并不占用CPU也不占用内存，所以严格来说它不是资源问题，而是程序bug。子进程结束时会发信号给父进程，由父进程调用wait()来完成回收，如果父进程没做这件事，子进程就会变成僵尸。处理僵尸进程的唯一办法是处理掉它的父进程——要么修复父进程的逻辑，要么直接重启这个服务的父进程。用户无法强制回收别人家的孩子，kill -9对僵尸进程无效，这一点很多人试过之后才明白。
4. 用批处理模式做持续采样：从命令到监控脚本
top的批处理模式是我最喜欢的部分，因为它让top从“一次性的排障工具”变成“能持续记录现场的数据源”。线上问题最怕的是“复现不了”，而定期落盘的top日志相当于给系统的运行状态持续拍照，出问题之后翻日志就能看到事发前后的资源变化过程。
4.1 -b -n -d的组合逻辑与第一个坑
批处理模式的核心参数组合是-b -n -d。-b进入批处理，-n指定采样轮数，-d指定轮与轮之间的间隔秒数。比如top -b -n 5 -d 2表示每2秒取一次快照，连续取5次，整个命令大约耗时8秒。输出会按顺序一帧一帧打印，进程列表在每帧重复出现，可以直接重定向到文件。
这里有一个我踩过好几次的坑：top -b -n 1的第一次采样数值经常“不准”。原因在于top计算CPU使用率时用的是两个采样点之间的差值，而第一次采样没有前值，它会用系统启动时间作为起点来计算平均值，所以你看到的%CPU和%Cpu(s)可能是“自开机以来的平均”，而不是“当前的值”。这正是很多人在脚本里发现CPU明明已经飙高但top -b -n 1显示正常的原因。解决方式很简单：取两次采样，丢掉第一次，用第二次之后的结果，也就是top -b -n 2 -d 1，然后从输出里取后半部分。
4.2 一个能直接拿来用的采样脚本
下面这个脚本是我在服务器上实际用过的简化版，它会每隔5秒采集一次系统的首部信息和Top进程，追加写入日志文件。脚本里保留了“取第二次采样”的经验，也通过临时文件避免了管道截断对top采样的影响：
#!/bin/bash # /usr/local/bin/topmon.sh LOG_FILE="/var/log/topmon.log" INTERVAL=5 while true do # 取两次采样，第二次的CPU百分比更有参考价值 top -b -n 2 -d 1 > /tmp/topmon.$$ 2>/dev/null { echo "" echo "===== $(date '+%Y-%m-%d %H:%M:%S') =====" head -n 35 /tmp/topmon.$$ } >> "${LOG_FILE}" rm -f /tmp/topmon.$$ sleep $((INTERVAL - 2)) # top采样本身耗时约2秒，补偿一下 done跑起来之后，tail -f /var/log/topmon.log就能实时看到系统状态。每次记录前50行左右，既包含首部全部信息，也包含CPU占用最高的Top进程。日志会随时间增长，建议配合logrotate做轮转，按天或按大小切割，免得日志把磁盘塞满。
4.3 采样间隔、落盘节奏与日志清理
采样间隔不是越小越好，要结合业务场景和磁盘空间来定。一般故障现场排查只需要秒级采样，但如果要长期稳定运行，建议间隔至少10秒以上。日志的增长量很容易估算：一次快照约3到5KB，5秒一次就是每小时约3MB，一天约70MB。如果你有10台机器都这样采，一个月就是20多GB。所以我通常建议间隔拉长到30秒到60秒，只保留7到14天日志，磁盘紧张就再缩短。
还可以考虑按进程维度过滤，减少无用数据。比如top -b -n 2 -d 1 -p 12345只监控指定PID，或者配合-u只采集某个用户的进程，这样日志体积能缩小很多。另外，如果只关心CPU和内存的顶部状态，可以不用head截取，而是配合grep加awk从输出里提取关键行，这样写入的只是几行汇总数字，长期监控的成本低得多。
5. top数据从哪来？以及几个容易误判的坑
最后这部分说说top的运行机制和几个我认为最容易踩坑的地方。理解数据来源能帮你解释很多“诡异”现象，而知道它的边界能帮你在合适的场景下选用更合适的工具。
5.1 top背后的/proc数据源
top本身不是一个性能采集工具，它更像一个“读卡器”，所有数据几乎都来自Linux的/proc虚拟文件系统。首行的load average读取的是/proc/loadavg，CPU各状态百分比来自/proc/stat，内存信息来自/proc/meminfo，每个进程的CPU和内存数据则分布在/proc/[pid]/stat和/proc/[pid]/status里。这意味着两件事：第一，top不会额外增加太多系统开销；第二，如果你在容器里运行top，看到的可能是宿主机的全局数据而非容器自身的资源限制视图，因为/proc是内核暴露的，容器技术并没有完全隔离它。这在使用Docker/K8s排查问题时是一个很容易被忽略的坑。
理解了数据源，还有一个实际价值：当你怀疑top显示不更新或者数值异常时，可以手动去看/proc/stat里的cpu行。这一行从系统启动开始累计递增，top只是每隔一段时间读一次算差值。如果你在脚本里想自己计算CPU使用率，直接读这个文件是最底层的做法，很多监控agent就是用它来算的。
5.2 多核百分比超过100%不是bug
我收到过好几次类似的疑问：“为什么有个进程CPU占用显示300%？是不是算错了？”这其实不是bug，它恰好说明进程利用了多核并行。前面提到过，top里的%CPU是相对单个CPU核心来计算的，所以在4核机器上，一个进程最多能显示接近400%，在8核机器上能显示接近800%。看到超过100%的数值，不要大惊小怪，结合机器的核数来判断这个进程是不是真的吃满了资源。
真正容易被误判的是%Cpu(s)这一行顶部的合计值。不管机器有多少核，这一行的us、sy、id等都是按照所有核心加总后再归一化的百分比，所以它们的合计约等于100%乘以核数，但实际上top显示的是归一化后的总和基本在100%左右。这跟进程的%CPU表示方式不是同一个口径，放在一起看的时候很容易把自己绕晕。记住，进程的%CPU超过100是正常的，首行的CPU状态百分比也根本不需要凑成100%。
5.3 什么场景下top不够用，需要搭配其他工具
top擅长回答“现在系统整体负载高不高、哪个进程最活跃”，但它的粒度不够精细：它看不到是哪个磁盘分区在忙，看不到具体是哪个网络连接在消耗带宽，也看不到系统调用层面的耗时分布。所以真正深挖问题时，我一般会用它先做初筛，再针对性上更精确的工具。
如果wa高、大量进程处于D状态，用iostat -x 1看每块盘的%util和await，能直接定位到坏盘或者慢盘；如果si高、网络包处理消耗大量CPU，用perf top或者netstat -s看协议栈的统计；如果经常出现sy偏高，用pidstat -w看看进程的上下文切换次数，可能是线程数太多引起的锁竞争。对于监控告警，top的批处理模式最多算是轻量方案，生产环境要搭正经监控还是得用node_exporter加Prometheus这类体系，top适合的是快速定位和不方便装agent的场合。
我在实际使用中还有一个小体会：top看久了会产生一种“数值焦虑”，特别是看到负载忽高忽低、CPU百分比跳来跳去的时候。但性能排查讲究的是持续性，单次快照说明不了问题，至少观察10秒到1分钟的走势，综合多个采样点再下判断。top给你的是一张地图，而不是一条结论，真正有价值的还是你基于这些数据形成的判断链路。
 父选择器实战指南：从语法到性能优化)
