
top命令应该是Linux运维工具箱里出场率最高的命令之一。不管是刚入行的新手还是干了多年的老运维排查服务器问题第一个敲的几乎都是top。它能在终端里实时展示系统整体的运行状态包括CPU占用、内存使用、负载情况以及每一个进程的资源消耗而且支持按键交互可以立刻按CPU或内存排序直接锁定谁在拖垮整台机器。这篇文章写给所有被top输出搞得一头雾水的朋友——无论你是刚开始学Linux还是已经能看懂基本输出但想深入了解字段细节和批处理玩法这篇文章都会给你一套可以直接上手的完整思路。我会把top的输出逐行拆开讲把每一个数字背后的含义讲清楚把快捷键和命令行参数整理成速查表再用真实的排查场景演示怎么用top解决CPU飙高、内存泄漏这类典型问题。1. top命令的核心价值与适用场景1.1 一块实时滚动的进程仪表盘很多人第一次接触top是在百度搜索Linux查看进程命令的时候。搜索结果里通常同时出现ps和top很多人试了一下发现ps输出完就结束了而top界面会一直刷新、还能按按键于是默默记住了top是动态的。这个直觉是对的但还不够全面。top的名字来自Table of Processes它的核心设计目标就是在终端里持续展示系统运行的全景图。你打开top之后看到的不仅仅是一个进程列表而是一个实时更新的仪表盘系统负载有多高、CPU到底忙不忙、内存还剩多少、哪个进程在疯狂吃资源这些信息全都在同一个界面里。它和ps最大的区别在于实时和交互。ps是拍一张照片定格在命令执行那一刻的系统状态top是一段持续播放的视频默认每3秒刷新一次并且支持你通过键盘指令改变排序方式、筛选进程、甚至直接杀掉异常进程。这个特性决定了它的使用场景非常明确适合做首诊也就是快速判断服务器当前是不是出了问题、问题大概出在哪个方向。但要注意top本身只是一个观测工具它告诉你谁在吃CPU、谁在占内存但不会告诉你这个进程为什么这么做——后面的深入排查还需要结合其他工具。1.2 为什么top天天用却总有人用不好我见过不少同事top用了好几年每次敲完top就盯着前三行看然后按一下q退出接着继续用ps aux慢慢找。说实话这有点浪费top的能力。总结下来大多数人用不好top主要是踩了三个坑第一个坑是只看前三行。很多文章和教程从一开始就只教人看load average、CPU百分比和内存使用量导致很多人以为top的精华就在摘要区。但实际上摘要区只是告诉你系统整体状态怎么样真正告诉你问题出在哪个进程的是下面那个进程列表区。你看到CPU idle为0%然后呢如果不知道是哪个进程在刷CPU这个结论没有任何排查价值。第二个坑是不理解load average。很多人看到服务器load average是50第一反应是完了要挂了。但load average的数字本身没有绝对意义它跟CPU核数强相关。一台128核的服务器load average是50说明系统闲得很一台4核的服务器load average是50那确实已经严重过载了。后面我会专门讲怎么正确解读这个数字。第三个坑是不会用快捷键。top的交互能力是它区别于ps最大的优势但很多人从来不用。只会看默认排序——按CPU降序遇到内存问题就傻眼了不知道怎么切换成按内存排序。实际上top的交互操作非常直观按键就完成比反复加参数舒服得多。这篇文章后面会专门用小节把快捷键讲透。2. top命令输出逐行拆解第一屏到底在说什么2.1 摘要区五块信息先看整体再看局部当你敲下top命令看到的第一屏信息可以分为两大区域上方的摘要区以及下方的进程列表区。摘要区默认占据前5行每一行都有大量信息我逐个拆开讲。第一行是系统概况从左到右依次是当前时间、系统已运行时长、当前登录用户数、系统负载。举个例子top - 14:22:31 up 38 days, 3:12, 2 users, load average: 0.08, 0.03, 0.01up后面的38 days代表服务器已经连续开机运行了38天这个数字在排查服务器是不是被重启过时很有用。load average后面跟了三个数字分别代表过去1分钟、5分钟、15分钟的平均负载。这三个数字是判断系统负载趋势的关键如果1分钟数值明显高于15分钟数值说明系统负载正在快速上升如果15分钟数值一直很高说明已经持续过载一段时间了。第二行是进程统计Tasks: 203 total, 1 running, 201 sleeping, 0 stopped, 1 zombietotal是进程总数running是正在运行的进程数sleeping是休眠中的进程数stopped是被停止的进程数zombie是僵尸进程数。这里我建议你多留意两个数字running和zombie。running长期大于CPU核数说明CPU调度很繁忙zombie出现数量增多说明可能有父进程没有正确回收子进程退出状态等排查僵尸进程时这个行就是第一个线索。第三行是CPU状态百分比也是被误解最多的一行%Cpu(s): 2.5 us, 1.2 sy, 0.0 ni, 96.0 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st每一项的含义如下us是用户态CPU时间百分比指进程直接运行在用户模式下消耗的CPUsy是系统态CPU时间百分比指内核消耗的CPUni是调整过优先级的进程消耗的用户态CPUid是空闲CPU百分比wa是等待I/O完成的CPU时间hi是处理硬中断消耗的CPUsi是处理软中断消耗的CPUst是被虚拟机管理程序偷走的CPU时间只在虚拟化环境下出现。重点讲两个容易被忽略的值。wa如果一直很高说明系统在等待磁盘或者网络I/O这时候CPU其实并没有被计算程序占满瓶颈在存储或者网络设备上盲目扩容计算资源是没用的。st如果在云服务器上长期不为0说明宿主机上其他虚拟机在抢占物理CPU资源这种情况你该考虑换实例规格或者调整业务高峰时段了。第四行和第五行是内存信息KiB Mem : 7881344 total, 512388 free, 3892780 used, 3476176 buff/cache KiB Swap: 0 total, 0 free, 0 used, 0 avail Mem注意这里不同发行版的显示可能略有差异比如有的是GiB单位有的没有avail Mem字段。total是物理内存总量free是完全没有被使用的内存used是被进程实际使用的内存buff/cache是用于缓存和缓冲的内存。很多人看到used很高就很紧张其实buff/cache在内存充足的情况下本来就应该尽量多用因为Linux会主动用空闲内存做磁盘缓存来提升读写性能这部分内存在进程需要时会被释放出来。真正要关注的值是avail Mem它表示在不触发大量换页的情况下还能分配给新进程的内存量这个数值更能反映实际可用内存的余量。2.2 进程列表区每个字段都是一条破案线索摘要区往下就是进程列表区默认按CPU使用率从高到低排列。每一行代表一个进程字段比较多很多人一看就晕其实拆开看就清晰了。默认情况下一行进程信息的字段顺序是PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMANDPID是进程IDUSER是启动进程的用户PR是进程优先级数值越小优先级越高NI是nice值可以通过nice命令调整范围一般是-20到19同样越小越优先VIRT是虚拟内存大小包含进程实际使用的内存、映射的库、共享内存以及可能尚未实际分配的内存空间RES是常驻内存表示进程当前实际占用的物理内存大小SHR是共享内存大小指进程和其他进程共同使用的内存。S代表进程状态常见的有R运行中、S休眠、D不可中断的睡眠通常是在等待I/O、Z僵尸、T停止。%CPU是该进程占CPU的百分比%MEM是进程RES占物理内存的百分比TIME是进程启动以来累计消耗的CPU时间COMMAND是命令名。这里有几个新手特别容易迷糊的点。第一%CPU为什么可以超过100因为top统计的是进程占用的CPU时间占整个时间片的比例在多核系统上一个进程最多可以用满一个核就是100%但如果这个进程开了多线程且多个线程同时跑在不同核上%CPU就可能显示为150%、200%甚至更高。判断标准很简单%CPU超过100%说明这个进程确实在用多核并行计算如果此时CPU整体us很高那它就是主要消耗者。第二VIRT特别大不代表内存泄漏。VIRT包括进程映射的共享库、栈、堆、以及声明但未实际写入的内存区域。很多程序声明了很大的虚拟内存空间但从来不会全部实际占用。判断进程是否真的吃掉大量物理内存要看RES而不是VIRT。RES大且持续增长才说明进程正在真实消耗物理内存。第三TIME和%CPU的意义完全不同。TIME是累计值表示这个进程从启动到现在一共消耗了多少CPU时间格式是分钟:秒。%CPU是当前快照反映的只是最近一段时间内的瞬时占用。一个%CPU只有1%的进程TIME可能累计几十个小时说明它长期存在且持续小规模消耗CPU一个%CPU为100%的进程TIME可能才几秒因为它刚启动不久。排查问题是看%CPU找当前热点看TIME找长期大户。2.3 刷新逻辑与排序规则别等错了地方top默认每3秒刷新一次屏幕这个间隔决定了你看到的数据颗粒度。%CPU本质上是一个时间窗口内的平均占用率间隔越短瞬时性越强间隔越长平均值越平滑。如果你觉得某个进程的占有情况忽高忽低很难判断可以按s键修改刷新间隔比如改成5秒或10秒让数据稳定一些再观察。排序规则上top启动后默认按%CPU降序排列。这意味着列表第一个进程就是当前CPU占用最高的进程。但需要注意这个排序并不是固定的交互模式下你可以随时按P、M、N、T键切换排序字段。很多人不知道这一点遇到内存问题还傻乎乎地在CPU排序列表里翻找其实按一下M键进程列表就变成按内存占用排序了效率翻倍。另外要注意的是进程列表里显示的进程数量可能只是系统进程总数的一部分。默认情况下top只显示一屏能放得下的进程如果你要看的进程恰好排在一百名开外直接看不到。解决方法是按f进入字段管理或者用命令行参数-n设置显示数量不过更常用的是直接按u按用户筛选或者用-p指定PID。3. 交互式操作像老手一样玩转快捷键3.1 第一梯队必须背下来的八个按键top启动后进入了交互模式这时候按任何按键都会触发对应动作。以下这几个按键是我认为必须先掌握的它们能覆盖日常排查80%的需求。P键按CPU使用率降序排列这是默认排序按一下就回到CPU视角。M键按内存占用率降序排列排查内存问题时的第一选择。N键按进程PID排序当你想按启动顺序找进程时会用到。T键按累计CPU时间排序可以用来找出长期吃CPU的老家伙。k键是杀掉进程。按k之后top会提示你输入PID输入后回车再输入信号编号。默认是15SIGTERM也就是优雅终止信号大部分情况下建议先用15给进程一个自己清理退出机会。如果进程不响应再用9SIGKILL强制杀掉。我自己的习惯是能用15就不用9除非确认程序本身已经卡死无法响应。r键是重新调整进程的优先级也就是修改nice值。按r后输入PID然后输入nice值范围是-20到19。普通用户只能调高nice值降低优先级只有root才能调低nice值提高优先级。1键是切换CPU统计信息的展示粒度。按一下第三行的%Cpu(s)会展开成每个CPU核心的单独统计再按一下又合并回总览。排查多核CPU负载不均问题时这个键能帮你快速判断是单个核被打满还是所有核都忙。q键退出top进入top后唯一不会误伤系统的操作按多少次都不会有副作用。3.2 进阶交互筛选、字段管理、高亮与配置保存上面那些键解决的是按什么排序的问题下面这些解决的是显示什么内容的问题。f键进入字段管理界面。在这个界面里你可以选择哪些字段显示在进程列表中哪些字段隐藏。每行一个字段按空格键切换选中状态按d键可以调整字段顺序按q返回。举个例子如果你觉得USER字段对你没用可以在这里关掉让列表更短更适合截图记录。这个功能用得少但一旦要用就很香。o键是过滤器。按o后在底部会出现一行过滤表达式编辑框你可以输入类似RES100000这样的规则top就会只显示RES大于100MB的进程。注意不同版本的top语法略有差异老版本top用awk风格过滤语法新版本支持更丰富的操作符。建议在服务器上先按o试一下看看版本支持的说明。过滤器在进程数几百上千的场景里非常有用平时小服务器上用得少。b键用于高亮显示。按一下btop会用加粗或反色方式高亮显示当前排序字段所在列和当前运行中的进程再按一下取消。在密密麻麻的进程列表里高亮能让你迅速把视线聚焦到关键行。x键高亮排序的列y键高亮运行中的进程。两个可以配合b键一起用效果是把排序字段的整列以及当前处于运行状态的进程行都标出来。虽然配色看起来比较花哨但对于快速定位确实有帮助。最后是W键保存当前配置。这个键我强烈建议用一下。你调整完排序字段、隐藏了不需要的列、设置了高亮方案之后按一下Wtop会把当前配置写到用户目录下的配置文件里下次启动top自动加载。也就是说你可以花五分钟把top调成自己习惯的样子然后一劳永逸。很多老运维的top界面和默认长得完全不一样就是因为用了W保存。3.3 冷门但实用的几个交互玩法除了上面说的还有几个交互键我提一下不常用但特定场景很实用。u键是按用户名筛选进程。按下u输入用户名top就只显示该用户的进程。如果服务器上有多个业务账号想单独看某个账号的资源占用这个键比grep进程列表快得多。V键切换树状视图。按V后进程列表会按父子关系以缩进方式展示类似pstree的效果。在排查僵尸进程、理清进程启动链路时树状结构比扁平列表直观得多。H键切换线程模式。按H后top会展开显示每个进程内部的线程对分析多线程应用比如Java应用非常有帮助。当你看到某个进程的总CPU占用不高但业务确实很卡顿就可以切到H模式找到具体是哪个线程在消耗资源。z键切换颜色显示。新版top支持彩色输出用不同的颜色区分不同状态的行和列视觉上更清晰但对服务器性能没有任何影响纯粹是个人偏好。4. 命令行参数与批处理模式从人工操作到脚本自动化4.1 常用参数及其适用场景top除了交互模式还能通过命令行参数直接指定运行方式。很多人在交互界面里看惯了反而忽略了这些参数。实际上参数配合重定向和脚本能完成大量自动化监控需求。-d参数指定刷新间隔单位是秒。比如top -d 1表示每秒刷新一次top -d 5表示每5秒刷新一次。注意交互模式下按s键也能改间隔但参数指定方便脚本调用。间隔越短对系统资源的消耗越大不建议在性能监控场景下用低于1秒的间隔跑很久。-n参数指定退出前刷新的次数。top -n 1表示只刷新一次就退出。这个参数配合-b参数是最经典的组合可以做到一次性抓取当前top输出不进入交互界面效果类似ps但多了一层摘要区信息。-b参数是批处理模式。在批处理模式下top不会进入交互界面而是把输出直接打印到标准输出可以重定向到文件或者管道给其他程序处理。这个模式是写监控脚本的基础。注意批处理模式下默认仍然会按3秒间隔持续刷新如果不加-n限制它会一直刷下去直到你手动kill或者用超时命令截断。-p参数指定监控的进程PID可以跟多个。使用-p后top只显示指定PID对应的进程信息不会显示系统全部进程。这个参数很适合针对单个业务进程做专项监控比如只观察Java进程的CPU和内存变化。-H参数指定线程模式显示等价于交互模式下的H键。脚本里想分析某个进程的线程消耗时可以配合-p一起使用top -H -p 1234 -n 1 -b一次性打印出指定进程的全部线程资源消耗。这个组合我在排查Java线程问题时用过很多次比先抓线程号再去查堆栈要高效很多。-o参数指定排序字段比如top -o %MEM表示按内存使用率降序排列top -o TIME表示按累计CPU时间排序。这等价于按对应快捷键但在脚本里写死参数比依赖交互按键更可靠。-u参数指定用户top -u nginx只显示nginx用户的进程。4.2 批处理模式实战写一个覆盖日常需求的监控脚本理解了参数我们来做一个可以直接落地的脚本。场景是这样的服务器偶尔CPU飙高但人不可能24小时盯着终端我们写一个脚本定时抓取top输出把CPU和内存占用最高的几个进程记录到日志文件里。#!/bin/bash # 每5分钟采集一次top数据保留最近7天日志 LOG_DIR/var/log/topmon mkdir -p $LOG_DIR while true do TIMESTAMP$(date %Y%m%d_%H%M%S) { echo $TIMESTAMP # 抓一次完整top信息batched mode top -b -n 1 -d 3 # 再用一次采样单独提取CPU占用前三的进程 echo --- Top CPU processes --- top -b -n 1 | awk NR7 NR17 {print $1, $9, $12} echo } $LOG_DIR/top_$(date %Y%m%d).log # 只保留7天内的日志 find $LOG_DIR -name top_*.log -mtime 7 -delete sleep 300 done这个脚本的逻辑很简单每5分钟采集一次把完整的top快照和CPU占用最高的前十个进程记录到按日期分文件保存的日志中然后自动清理7天前的旧日志。这里有个细节值得说明用top -b -n 1 -d 3而不是直接top -b -n 1是因为批处理模式下单次采样时-d 3表示采样前先等待3秒再采集CPU数据这样拿到的%CPU值才是基于一个完整时间段的平均值而不是top刚启动时的瞬时值。直接top -b -n 1采到的CPU数据经常不稳定我在这个细节上吃过亏。配合crontab使用的话也可以去掉while循环直接在计划任务里每分钟执行一次采集效果相同。采集出来的日志是纯文本后续可以用grep、awk继续处理也可以直接拖到本地用文本对比工具分析某段时间内CPU占用最高的进程变化。4.3 参数组合的常见坑与正确姿势批处理模式用久了会踩一些比较隐蔽的坑我列几个最常见的。第一个坑是批处理模式不带-n会无限输出。很多新手写top -b top.log以为会输出一次结束结果文件越来越大磁盘直接被打满。正确写法是top -b -n 1 top.log或者用timeout命令限制执行时间比如timeout 3 top -b。第二个坑是top -b -n 1的CPU数据不准。原因上面说过top在第一次采样时没有历史数据会直接读取启动时刻的CPU计数导致第一屏的%CPU值偏高或者为0通常要第二次采样才趋于稳定。解决方法是采集时写-n 2然后只看最后一次输出或者加-d参数预等待一个刷新周期。更稳妥的写法是top -b -n 3 -d 1 | sed -n 8,20p也就是用三次采样取最后一批数据。喜欢精确数据的人可以这样用。第三个坑是批处理模式不支持某些交互功能。比如字段高亮、颜色显示在批处理模式下是无效的这些属于终端渲染范畴。批处理模式输出的是纯文本方便文本处理但视觉效果会大打折扣。如果需要彩色结果请回到交互模式人工查看。5. 实战场景用top排查性能问题的完整思路5.1 场景一CPU使用率飙高如何锁定元凶某个业务反馈接口响应变得非常慢登录服务器第一件事就是敲top。看到的结果通常是%Cpu(s)那行里us很高id接近0。这时候第一个动作不是继续盯着摘要区而是马上把视线移到进程列表区看排名第一的进程是谁。假设top显示某个进程的%CPU达到了180%COMMAND看起来是一段随机字符串或者是一个你不认识的名字。这种情况大概率是遇到了挖矿木马或者恶意脚本。第一时间按k输入PID先发SIGTERM也就是信号15观察几秒。如果进程消失再检查一下crontab、启动脚本和系统服务找出它是怎么被拉起来的否则杀掉还会重启。如果SIGTERM无效再改成SIGKILL强制结束。如果排名第一的进程是你自己的业务进程比如Java进程或者PHP进程那就不能简单杀掉了。先按1键看看是所有核心都高还是只有个别核心高。如果是单个核心的us很高但其他核空闲说明程序里有一个线程在死循环可以切到H模式找到具体线程号再用其他工具导出线程堆栈分析。还有一种情况%Cpu(s)那行us不高id也不低但系统确实卡。这时候重点看wa。如果wa很高说明CPU在等待I/O完成。可能的原因包括磁盘性能不足、日志写入频率过高、或者数据库在做大量磁盘读写。用top确认wa高之后再配合iostat和lsof找到具体是哪个文件在被打就能一步步缩小范围。5.2 场景二内存泄漏的早期信号与RES判读内存泄漏排查是top的另一个强项。假设某天发现服务器内存持续走高业务没重启前内存一天比一天少。这时用top -M按内存排序观察进程列表最前面的几个进程。重点看RES列。内存泄漏的特征是某个进程的RES随时间单调增长重启进程后数值回落过一段时间又开始涨。注意RES增长不见得就是泄漏——Java应用堆内存会随业务量动态伸缩文件缓存也会被算到buff/cache里而不算到进程RES。要区分这两者看两点一是RES增长是否伴随系统可用内存明显下降二是增长是否与业务流量相关。如果流量平稳但RES持续线性增长大概率有泄漏。还需要注意第四行内存总和里的avail Mem字段。如果avail Mem长期偏低即使RES没有异常暴涨也说明系统整体内存余量不足。这时候再用top去看能不能找到吃内存的进程如果找不到再考虑是不是页表、内核模块等非进程内存消耗。单纯靠top看不到内核态内存的明细需要配合cat /proc/meminfo以及slabtop这类工具深入排查。内存问题还有一个常见场景top显示某个进程RES只有几百MB但buff/cache占用高达几个GB。这不是泄漏是Linux正常的缓存策略。磁盘文件被频繁访问后内核会尽量留在page cache里以提高性能。这部分内存在业务需要时会自动释放不需要人为干预。很多刚接触Linux的人看到free命令available很少就紧张其实在top里观察avail Mem才是更准确的判断依据。5.3 场景三load average很高但CPU空闲的真相排查服务器时经常遇到一个矛盾现象load average很高比如到了20甚至30但%Cpu(s)那行的id还有80%以上。如果对负载概念理解不深看到这个场面会一头雾水。这里的核心要懂一个原理load average统计的是可运行进程和不可中断睡眠进程的数量而不只是CPU忙不忙。也就是说等待I/O的进程也会被计入负载。当大量进程阻塞在磁盘I/O等待上时load average会飙升但CPU本身可能闲着没事干。用top排查时发现load高但CPU id高就要重点看wa字段。如果wa同样很高那说明I/O是瓶颈。这时候再回到进程列表找到S状态为D的进程——D是Uninterruptible Sleep也就是不可中断睡眠绝大多数D状态就是卡在磁盘或者网络I/O上。如果D状态进程数量多那么负载高就很好解释了。另一种情况是load高、id高、wa也高但进程列表里没有明显的D状态进程。这时候可以再看top摘要区第二行的running进程数和sleeping进程数如果running数量一直大于CPU核数说明有大量进程在CPU运行队列里排队只是因为每个进程占用时间片极短看起来CPU使用率不高。这种情况的常见原因是频繁上下文切换或者系统里大量短生命周期的进程在反复创建销毁。配合vmstat、pidstat这些工具可以进一步确认。这个场景想表达的关键是top的摘要区只是现象必须结合进程区、CPU状态行的多个字段以及对Linux调度和I/O模型的理解才能做出正确判断。单看任何一个指标都可能得出完全错误的结论。6. 常见误区和避坑指南6.1 四个高频误解一次说清误区一系统CPU使用率是每个进程百分比相加之和。从数学上看进程列表里的%CPU加起来确实约等于总的us加sy但实际因为多核、采样时间窗口以及I/O等待等因素两者并不严格相等。而且%CPU最大值不一定只有100%多核并行可以把多个核都用起来。判断系统整体CPU使用率老老实实看第三行的%Cpu(s)不要拿进程列表反推。误区二VIRT很大就等于内存泄漏。前面已经说过VIRT是虚拟地址空间大小很多进程映射了大片地址空间但从未实际触碰。真正需要关注的是RES以及RES随时间的变化趋势。如果RES稳定VIRT再大也不慌如果RES持续增长并伴随系统可用内存下降那才需要进一步查泄漏。误区三load average超过CPU核数就一定会卡顿。load average高不等于立即卡死判断依据更多是业务的响应时间和系统实际行为。有时候一个I/O密集型的批处理任务会让load飙升但交互式业务完全不受影响。判断要不要扩容建议结合吞吐、延迟、CPU使用率、I/O等待等多项指标综合判断别只看一个load就下结论。误区四top看到的进程内存就是进程实际占用的全部内存。RES只是物理内存部分不包含进程共享的内存段、内核为这个进程分配的少量资源以及进程和磁盘交互的缓存。更完整的进程内存视图要用smem、pmap这类工具去查看。top适合做宏观定位不适合做精确计量。6.2 问题速查表遇到这些情况怎么处理现象可能原因首轮排查动作us高、id低计算密集型任务或死循环按P排序找CPU大户切H模式看线程sy高、id低系统调用频繁或内核瓶颈配合strace看进程系统调用wa高、id低磁盘或网络I/O瓶颈配合iostat看具体设备负载st高、id低虚拟机资源被抢占确认宿主机运行状态考虑迁移或升配load高但id高大量D状态进程在等待I/O找D状态进程查I/O来源zombie进程数增长父进程未回收子进程找到父进程检查业务代码或重启服务RES持续上涨内存泄漏或业务缓存增长按M排序观察趋势必要时导出堆栈%CPU超过100%多线程并行执行这是正常现象说明进程用了多核进程列表找不到目标进程列表只显示一屏按u按用户筛选或-p指定PID单个CPU核高其他核闲单线程热点切H模式找线程优化并行度这张表我建议收藏起来排查的时候对着看能少走很多弯路。当然表格列的是方向具体定位还是要靠后面接其他工具逐步确认。6.3 top的局限性什么时候必须换工具top是个很好的第一站但它不是终点。top看不到的东西很多比如单个进程的系统调用细节top看不到磁盘设备的实时读写速率top只能间接地看wa看不到具体数值进程数的趋势变化、网络连接状态、具体进程的页表开销top也都不擅长。定位到方向后需要按需切换工具。排查CPU微观使用用pidstat和perf能看到某个PID的CPU消耗构成排查磁盘I/O用iostat和iotop能看到设备级别的读写速率和I/O等待队列排查内存细节用smem和pmap能看到进程映射的每一段内存需要历史数据做趋势分析用sar可以回放过去某个时间点的CPU、内存、I/O、网络数据。htop是top的增强版支持彩色显示、鼠标操作、树状视图交互体验更好但本质还是同一类工具不能替代深入的专项工具。我个人比较推荐的做法是top做第一诊断发现问题方向之后用对应专项工具深挖。每个人都可以根据自己的习惯组合一套工具链重点不是工具多而是知道什么场景换什么工具。top负责帮你找到可疑目标其他工具负责证明或排除目标这个思路比单纯记忆命令用法重要得多。最后分享一个小技巧也是我自己用top踩过坑之后养成的习惯如果你希望拿到一个相对稳定的CPU快照尽量使用top -b -n 3 -d 1而不是top -n 1。原因是第一次采样没有历史数据CPU值往往偏高或偏低后面的采样才更接近真实水平。另外保存top配置后别忘了用文件的权限保护因为这份配置里会记录你设置的显示方案和过滤规则虽然没有敏感信息但在多人共用的服务器上避免配置互相干扰也是良好习惯。top这个命令说简单也简单但真正把它吃透能让排查效率提高不少。