在CentOS 7.6的服务器上排查问题我第一个敲的命令绝大多数时候都是top。不管业务是突然变慢、CPU飙到报警、内存快被吃光还是负载高得莫名其妙top都是最合适的起点不需要安装任何额外工具默认装好就能用输出信息量极大还支持交互操作。这篇文章我会把CentOS 7.6上top命令的常用姿势完整过一遍从默认输出每一项的含义、交互快捷键到真实场景里的排查流程再到批处理采集和常见坑适合刚上手Linux的运维、后端开发也适合老手查漏补缺。1. 先认识topCentOS 7.6里最常用的性能第一入口1.1 top能解决什么问题CPU、内存与进程状态很多人对top的理解停留在“看CPU占用率最高的进程”这确实是最常用的场景但远不是全部。top命令在CentOS 7.6上来自procps-ng工具集它读取的是/proc虚拟文件系统下的运行数据所以它能反映的内容非常多每个CPU核心的使用率、系统整体负载趋势、内存和交换分区的总量与占用、所有进程的CPU和内存占用、进程运行状态、累计CPU时间、进程完整命令行甚至还能直接在交互界面里对进程发信号。实际工作中我用到top最多的几个场景包括线上应用CPU使用率居高不下时需要快速定位是哪个进程在消耗内存总量明明很大但业务频繁报内存不足时需要确认是否有进程异常增长系统load average偏高但CPU看起来不忙时需要判断是不是在等磁盘或网络多线程服务出现单线程热点时需要通过线程模式找到具体线程脚本巡检需要定时抓取系统状态时用批处理模式输出日志。这些场景里top都能给出第一手线索后面再配合其它命令做精细确认。1.2 默认界面逐行拆解别被十几行数字唬住直接在CentOS 7.6终端敲top会看到类似下面的输出top - 09:41:27 up 3 days, 5:22, 2 users, load average: 0.08, 0.03, 0.05 Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.3 us, 0.7 sy, 0.0 ni, 96.8 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 3865136 total, 473884 free, 1289244 used, 2102008 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 2240928 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1234 mysql 20 0 1622716 308020 9456 S 4.0 8.0 12:34.56 mysqld 5678 nginx 20 0 154832 25144 12344 S 0.3 0.7 2:05.18 nginx第一行最左边是当前时间09:41:27接着是up 3 days, 5:22表示系统已经运行了3天5小时22分钟后面2 users表示当前登录用户数。重点是load average后面的三个数字0.08、0.03、0.05分别代表过去1分钟、5分钟、15分钟的平均负载。判断负载是否正常不能只看数字大小要结合CPU核心数。假如是4核机器负载小于4说明任务基本能及时处理持续大于4说明存在排队需要进一步看是CPU不够还是进程在等IO。Tasks行比较直白total是系统里的任务总数running是正在运行或可运行的任务sleeping是睡眠中的任务stopped是停止的任务zombie是僵尸进程。如果zombie长期不为0通常说明父进程没有正确回收子进程需要追查。Cpu(s)行是很多人最容易误读的地方。us是用户态CPU占比sy是内核态占比ni是调整过nice值的进程占用的CPUid是空闲占比wa是等待IO完成的占比hi是硬中断si是软中断st是虚拟机被宿主机抢占的时间占比。判断CPU是否繁忙先看id是不是长期很低再看wa是否明显偏大。wa高说明有进程在等IO这时候盲目加CPU核心没有意义。内存行分Mem和Swap两段。Mem行里的total是物理内存总量free是完全没有被使用的内存used是已经被进程占用的内存buff/cache是用于缓存的内存量。这里容易产生疑问为什么used加free加buff/cache不等于total因为used统计时已经把内核持有的一部分算进去了实际以free命令的available字段为准。top在Swap行末尾还贴心地给出了avail Mem这才是估算的可用内存日常看内存够不够优先看这个值。进程列表区的关键字段VIRT是进程虚拟内存总量包括没实际分配的部分RES是常驻物理内存这个才是真正占用的内存SHR是共享内存比如动态库占用的部分S是进程状态%CPU是CPU使用率注意它可能超过100%因为多线程进程按各线程累加后相对单核百分比展示TIME是进程累计消耗的CPU时间。有了这些基础下面的交互操作和实战排查才有意义。2. 交互操作详解让top显示你真正关心的内容2.1 排序与筛选按CPU、内存、用户精准锁定目标top默认按CPU使用率从高到低排序但很多时候我需要快速换个维度。交互界面里按大写P是按CPU排序按大写M是按内存排序按大写T是按累计CPU时间排序按大写N是按PID排序。这几个键是排障时最高频的操作看到内存告警先按M看看RES最大的进程是谁想知道运行时间最长的老进程按T。另外小写字母x可以高亮当前排序列大写y高亮正在运行的进程方便截图汇报。如果进程数量太多可以用u键配合用户名筛选输入实际用户名后回车top就只显示该用户启动的进程。这个功能在多人共用的机器上很好用比如要看某个开发者提交的定时任务是否异常直接按u输入他的账号名比在满屏进程里找效率高得多。还有一个容易被忽略的键是c按一下能把COMMAND列从进程名切换成完整命令行很多脚本进程只看名字看不出问题完整参数一显示出来异常目录、错误配置一眼就能发现。2.2 多核与线程按1展开CPU按H进入线程视图默认的Cpu(s)行是所有核心汇总后的平均值这种时候看不出单核是否跑满。按数字1top会展开成每个CPU核心一行比如4核机器会出现4个Cpu0、Cpu1、Cpu2、Cpu3的独立行。处理CPU使用率异常时这一步非常关键如果整体us不高但某个核心接近100%说明存在单线程热点要配合后面的线程视图继续查如果所有核心都很高则可能是负载本身饱和或存在多进程并发问题。按大写H可以在进程视图和线程视图之间切换。默认top显示的是进程打开线程视图后同一进程的每个线程都会单独列出来TID会显示在进程号位置。我在排查Java应用、数据库这类多线程服务时几乎必开这个功能。比如某业务系统的CPU飙到200%切到线程视图后能看到是几个线程在疯狂消耗CPU再把这些线程ID转成十六进制就能和线程dump信息对应上直接找到出问题的代码位置。2.3 进程管理操作kill、renice、刷新间隔设置top不只是观察工具还能在交互界面里直接操作进程。按k可以给指定进程发送信号默认是SIGTERM提示输入PID后回车即可。实际使用时要非常小心建议先从15号信号开始给进程一个优雅退出的机会只有确认进程确实无法正常停止时再考虑用9号信号强制终止而且要先确认这个进程不是别的重要服务的子进程否则一个误操作可能连带把整个应用搞挂。按r可以调整进程的nice值也就是优先级。系统允许的nice范围是-20到19数值越小优先级越高。普通用户只能把nice往大了调也就是降低自己进程的优先级只有root可以把nice往低了调。这个功能适合处理“后台任务抢占太多CPU导致主业务变慢”的场景比如一个数据批处理任务在跑把它的nice值从0调到10它就不会频繁抢占交互业务的CPU了。刷新间隔也是可以改的。top默认约3秒刷新一次某些场景下这个间隔太长或太短。按s键后输入新的秒数可以设成1秒或更短也可以设成5秒减少刷新频率。实际上我不想让终端滚动太快时会把间隔设成5秒甚至10秒抓瞬时问题时设成1秒但要注意刷新越频繁top自身消耗的CPU也会略高一点。2.4 显示单位与界面定制把top调成适合自己的样子默认情况下内存数值以KiB显示数字位数一多就很难一眼读出大小。CentOS 7.6的top支持按e键循环切换进程内存显示单位从KiB、MiB到GiB按大写E切换顶部Mem和Swap行的单位。我用这套键位把顶部内存改成MiB或GiB读数据舒服很多。还有几个显示开关按l控制load average行的显示与隐藏按t控制Tasks和Cpu(s)行的显示模式切换按m控制内存行的显示模式切换。这几个键实际上是切换线条图还是数字文本在需要通过截图对外汇报时把界面调成简洁的纯数字模式更清晰。如果希望每次打开top都保持自己的习惯配置可以在交互界面里按大写Wtop会把当前设置写进用户主目录下的.toprc文件。下次再登录这个账号执行top它会自动加载这套配置。我一般会设好内存显示单位、关闭高亮色块、把刷新间隔固定下来然后按W保存省得每次都重新调整。3. 实战排查从top输出定位问题的完整流程3.1 CPU飙高排查先看us还是sy再决定往哪查CPU告警是最常见的故障类型我的排查顺序通常是这样的先敲top看整体Cpu(s)行然后按1看每个核心的分布。如果us很高说明是用户态程序在消耗CPU直接看进程列表里%CPU最高的几个进程如果是某个应用进程再按c看完整命令行确认是不是正常运行路径如果%CPU最高的进程看起来正常就要考虑是不是请求量涨了需要横向扩容而不是杀进程。如果sy很高情况就不一样。sy代表内核态CPU开销它高往往意味着系统调用频繁、进程频繁切换上下文、或者中断处理过多。这时候top里可能看不到某个进程的%CPU特别突出因为开销被摊到了内核身上。我的做法是配合vmstat看上下文切换和运行队列再结合业务最近变更判断是不是引入了高频系统调用。曾经排查过一个诡异的高sy问题最后发现是某个脚本在疯狂读取小文件每次读取都产生系统调用换成批量处理后才恢复。wa高则是另一条路。Cpu(s)行里的wa是等待IO的时间占比wa持续偏高时即便us不高系统也会表现得迟钝。这时候top的进程列表里可能很多进程停在S状态但整体load却在涨。需要先用iostat或vmstat确认是磁盘IO还是网络文件系统导致再决定优化方向。3.2 内存占用异常区分RES增长、cache与真实泄漏内存类问题用top排查时最容易犯的错是把buff/cache当成应用程序占用的内存。Linux内核会尽量利用空闲内存做页缓存这是正常的内存压力大时这些缓存会被自动回收。所以判断内存够不够优先看avail Mem这个字段它估算的是在不触发大规模交换的情况下还能分配多少内存。如果怀疑进程内存泄漏我会隔几分钟抓一次top快照按M排序后记录可疑进程的RES值持续多抓几次。RES持续上涨且不回落同时系统可用内存持续下降才是有意义的信号。还有一种情况是VIRT很大但RES不大这通常是进程申请了虚拟内存但还没实际写入并不能说明物理内存快满了比如某些程序预留了大段内存池。反之RES很大但VIRT不大说明物理页框被实打实占用了更值得关注。用top观察内存问题时我会同时记录Swap行的变化如果Swap的used开始出现并增长说明物理内存确实紧张部分页被换出去了。3.3 系统负载高但CPU空闲关注不可中断的D状态有一类问题最迷惑人load average很高但进top一看Cpu(s)行空闲id很高进程列表里也没有谁在大量消耗CPU。这种情况通常和不可中断睡眠有关。进程状态列S是睡眠R是运行D代表不可中断睡眠简单说就是进程正在等待某个IO操作完成期间无法被普通信号打断。load的计算把这种等待中的进程也算进去了所以会出现CPU空闲但负载高。遇到这种情况我在top里会专门看状态列统计有多少进程处于D状态。如果频繁出现D状态进程继续确认它们具体在等什么通常用iostat看磁盘利用率或者检查是否有挂载的网络存储出现超时。曾经有一次线上服务卡顿top看起来CPU很空闲但load到了几十最后发现是一块磁盘故障导致大量读写进程陷入不可中断等待这类问题光看CPU永远找不到答案。3.4 线程级定位多线程应用的CPU热点追踪多线程应用出现CPU热点时单看进程视图往往只能看到进程总体%CPU很高无法知道哪个线程在作怪。我处理某个Java服务CPU异常时会先用top找到进程PID比如12345然后执行top -H -p 12345直接进入该进程内部的线程视图。这时能看到每个线程的CPU占用线程ID显示在PID字段里。一旦锁定CPU最高的线程ID比如6789我会用printf %x\n 6789把它转成十六进制1A85再到应用的线程日志或线程dump里搜索这个十六进制线程号通常能定位到具体代码位置。这套流程在Java、Go、C多线程项目里屡试不爽。对应的如果在普通top界面里按了H进入线程模式同样能看到全局所有线程但数据量大会有点乱还是建议先用进程定位再带-p参数精确锁定。4. 批处理模式与脚本化把top变成巡检工具4.1 常用批处理参数-b -n -d -p组合套路有些时候没法在终端里盯着top看比如凌晨的低峰期巡检、需要记录历史趋势、或者要把数据喂给自动化脚本这时候就要用批处理模式。最基本的组合是top -b -n 1-b表示batch模式-n 1表示只输出一次快照。结合-d参数可以控制每次快照的间隔比如top -b -n 3 -d 5表示每隔5秒抓一次共抓3次适合观察短期趋势。如果只想看某个进程用-p指定PID比如top -b -n 5 -d 2 -p 12345。多个进程可以用逗号分隔PID列表。注意在批处理模式下top输出会包含两次快照之间的系统汇总信息比交互模式更适合直接落盘。我写巡检脚本时通常把输出重定向到文件再配合时间戳形成一份可追溯的性能记录。4.2 用文本处理解析top快照top的批处理输出还是给人看的格式想要提取某行数据需要用文本处理命令二次加工。最常用的做法是抓取进程列表区用awk过滤出需要的字段。比如要看PID 12345这个进程的RES内存可以把top -b -n 1 -p 12345的输出通过管道交给awk处理按进程名或PID字段匹配取出RES列。需要注意top的进程标题行以“PID USER”开头过滤时要先把表头和其他信息行去掉否则awk的字段序号会对不上。实际测试时我发现一个细节批处理模式下每次快照都会输出一次顶部汇总行和进程列表如果连续抓3次文件里会有3组数据。用grep过滤专属关键字时要把每一次快照当作独立记录编写解析脚本时最好按空行分组处理。对于长期趋势个人更推荐用监控系统采集但临时救急时top批处理快照比什么都不留强太多。4.3 结合监控系统做趋势采集直接用top做趋势采集只适合短时间应急因为top采样的是瞬时值而且每秒刷新会占用少量CPU长时间高频采集并不划算。如果要做系统化监控常规做法是让agent通过读取/proc/stat、/proc/meminfo、/proc/loadavg等文件采集指标入库后画曲线。top的批处理输出更适合做故障现场的数据留底比如在告警触发时自动执行top -b -n 3 /tmp/top_$(date %F_%H%M%S).log把当时的进程快照保存下来后续复盘时很有价值。我个人的习惯是监控系统负责常态趋势top负责现场快照。两者结合后判断问题的依据会更充分比如监控曲线显示内存缓慢增长一周现场top快照则能帮你确认具体是哪个进程在涨效率比纯看监控高得多。5. top之外再看什么黄金搭档与排障思路5.1 vmstat系统整体走势一屏看全top适合看“此刻谁在占用资源”但要理解资源变化的趋势vmstat是我紧接着会敲的命令。vmstat 1 5每1秒输出一次共5次每一行都包含运行队列、阻塞线程、用户态CPU、系统态CPU、空闲CPU、IO等待、交换分区换入换出、块设备读写等核心指标。top给出的是进程维度vmstat给出的是系统维度两者一交叉很多疑惑就解开了。比如top里看到很多进程在跑但CPU不高vmstat的r列显示运行队列很长b列显示有阻塞进程说明系统并不是真的空闲而是进程在排队等资源。再比如top里wa偏高vmstat的wa列也能同步看到并且还能看到块设备读写速度判断是不是磁盘吞吐到达瓶颈。5.2 pidstat与free进程维度和内存维度补盲区top虽然能看到进程的实时CPU和内存但缺少按时间维度的累计统计。pidstat命令可以按进程输出CPU、内存、IO等指标并且支持指定采样次数和间隔在分析进程CPU波动时比top更精细。比如要确认某个进程的CPU使用率是不是周期性飙升用pidstat -p 12345 1 10每1秒输出一次连续10次趋势就出来了。内存方面free -h可以看到Mem、buff/cache、Swap的整体分布avail字段也能显示估算可用内存。top和free对used的定义不同top的used不包含buff/cachefree的used计算方式则可能把部分缓存纳入统计两个命令数值对不上是正常的不要因此觉得自己判断错了。5.3 组合使用的心得先top定位再专项确认排障时我不建议只盯一个工具。我的常规路径是top先快速锁定可疑进程和整体方向再按方向选专项工具。CPU方向用vmstat、pidstat确认内存方向用free和pmap看进程地址空间IO方向用iostat或iotop看设备压力网络方向则用sar、ss看连接。top扮演的是“指路牌”角色它的价值在于让你快速知道该往哪个方向深挖而不是替你把所有问题都答完。还有一个容易踩的坑top输出是瞬时快照单看一次可能抓到偶然峰值也可能恰好错过问题。所以无论是交互模式还是批处理我都习惯至少看三次以上采样取变化趋势而不是单点数字。6. 高频问题与踩坑经验速查6.1 top的used和free命令结果对不上经常有人发现free命令显示可用内存还剩很多但top顶部显示的used已经占了大部分甚至两个命令的used对不上。这是因为free的used计算时会包含或者排除buff/cache的方式和top不完全一致而top顶部Mem行里的used也不等于进程列表里所有RES的总和。进程之间存在共享内存一个内存页可能被多个进程同时映射简单把RES相加会重复计算。排查内存问题时以avail Mem字段为准最省心它才是系统预估的可再分配内存量。6.2 %CPU和load average表现不一致%CPU是处理器的繁忙程度load average是运行队列和不可中断进程的综合指标两者不是一回事。比如8核机器跑一个单线程死循环%CPU可能只有百分之十几到百但整体load并不高因为只有一个任务在跑。反过来如果大量进程都在等磁盘IOCPU的id可能很高但load会涨。所以遇到top里CPU空闲而load高先去看S列有没有D状态再排查IO遇到CPU高而load不高则可以优先考虑代码或配置里的计算热点。6.3 任务数异常僵尸进程与内核线程top的Tasks行显示的是系统所有任务数量包括内核线程不只是用户进程所以看到total比较大别慌。真正需要警惕的是zombie长期存在僵尸进程不占CPU不占内存但会占进程表项并且说明父进程没有正确回收子进程。排查时可以用ps -ef | grep defunct查看僵尸进程的父进程PID再决定是重启服务还是修复父进程逻辑。另外在容器环境里执行top看到的Tasks是宿主机视角的不是容器视角很多刚接触容器的人在这里产生过误解。6.4 top自身开销大、输出与实际不符top默认3秒刷新一次在高频刷新或线程模式下会消耗少量CPU在低配机器上尤其明显。如果觉得top让系统更卡了可以按s把刷新间隔调大到5秒甚至10秒。还有一种情况是top显示的某个进程CPU过高但重复刷新后数值波动很大这通常是小进程的瞬时波动不用急着下结论。我在实际使用中的体会是top最适合用来快速建立全局印象遇到需要精准判断的场景还是多抓几张快照、多用专项命令交叉验证单靠一次top输出就拍板容易误判。