1. 为什么资深运维都离不开top一个真实排查场景先说个最常见的场景线上服务器突然告警说CPU使用率飙到80%以上业务响应变慢。你赶紧登上去第一件事做什么几乎99%的人都会条件反射地敲一个命令——top。top的全称是“table of processes”翻译过来就是进程列表。它能把系统当前运行的进程、CPU占用、内存占用、负载情况实时刷新在你的终端上像一块仪表盘一样。在Linux日常运维里top的地位很难被替代它默认安装在几乎所有发行版上不需要额外装任何东西一条命令按下去系统健康状态一览无余。有人可能会说我用htop、用glances、用web面板不是更直观但现实情况是很多生产环境是精简安装能用的只有一个终端。这时候如果你能把top玩明白等于随身带了一套完整的性能监控工具。再说就算你后面用上了各种监控平台在真正出问题的那几分钟里最快能拿到第一手证据的还是top。这篇内容适合谁刚接触Linux的开发者、做运维监控的初级工程师、经常跟服务器打交道的后端研发甚至是在自己电脑上装了Linux虚拟机自学的朋友。我会从top的界面怎么读、按键怎么用、参数怎么配一直讲到如何用top的批处理模式做自动化监控脚本最后再带上几个实战中高频踩坑的案例。尽量一次讲透让你看完就能上手用遇到问题也知道怎么深挖。2. top界面到底在说什么五大区域逐一拆解2.1 前五行系统概况从时间、负载到CPU内存我第一次用top的时候屏幕上哗啦啦刷出一大片数据说实话挺蒙的。但你要是把它拆成几个区域来看就非常清晰了。top默认输出可以分成两大块前半部分是系统概况后半部分是一个个进程的明细列表。咱们先看系统概况这五行。第一行是系统汇总信息长这样top - 10:35:20 up 27 days, 3:12, 2 users, load average: 0.52, 0.40, 0.35依次读下来是当前时间、系统开机时长、当前登录用户数然后是一个非常关键的指标load average。它后面跟三个数字分别代表过去1分钟、5分钟、15分钟的平均负载。这个数值的单位是“可运行进程数”不是CPU使用率很多新手在这里被绕晕了。判断负载高低要看机器有几颗CPU核心负载值除以核心数如果长期大于1说明任务在排队系统已经忙不过来了。第二行是进程任务统计Tasks: 186 total, 1 running, 185 sleeping, 0 stopped, 0 zombie这行告诉你当前系统里总共有多少进程其中多少在运行、多少在休眠、多少被停止、多少变成僵尸。僵尸进程那一项如果长期不是0就要留意了可能是某个父进程没有正确回收子进程的资源这个问题后面咱们单独聊。第三行是CPU状态明细%Cpu(s): 8.3 us, 1.2 sy, 0.0 ni, 90.1 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 stus表示用户态CPU占比sy是内核态占比ni是nice值调整过的进程占用id是空闲wa是等待IO完成hi和si分别是硬中断和软中断最后的st是steal time在虚拟机里才会出现表示被宿主机偷走的那部分CPU时间。这里最值得关注的是us和wa前者高说明有进程在做计算后者高说明磁盘或网络IO成了瓶颈。第四行和第五行是内存和交换分区KiB Mem: 8081140 total, 2214684 free, 3655228 used, 2211228 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 3700576 avail Mem注意新版本top默认单位是KiB有些发行版会显示成MiB。used是进程实际占用的物理内存buff/cache是内核用来做缓存加速的这两项要分开看。重点看最后一行的avail Mem这才是系统“真正还剩多少可用内存”的估算值它把可以回收的缓存也算了进去比单纯看free字段靠谱得多。2.2 进程明细区每一列分别代表什么概况区往下就是进程列表默认按CPU占用率从高到低排列。我在实际工作中发现很多人只盯着PID和%CPU这两列其他列是什么意思完全说不清这样排查问题容易卡壳。默认列大概是这样的PID进程ID、USER运行用户、PR内核调度优先级、NInice值、VIRT虚拟内存总量、RES常驻物理内存、SHR共享内存、S进程状态、%CPUCPU占用百分比、%MEM物理内存占用百分比、TIME累计CPU时间、COMMAND命令名称。这里有几个容易理解错的点。PR和NI啥关系PR是内核最终计算的优先级数值越小优先级越高NI是用户可以调整的nice值范围从-20到19你调整它PR会跟着变。普通用户只能把nice调高也就是让自己进程变得更“谦让”只有root能往低调提高进程优先级。VIRT、RES、SHR这三个内存值也容易看晕。VIRT是进程申请过的虚拟地址空间总量包含共享库和映射文件通常很大不用太在意。RES才是这个进程真正占用的物理内存数排查内存泄漏主要看它。SHR是和其他进程共享的那部分内存。我见过有人看到VIRT显示好几个G就慌其实绝大多数是虚拟映射没真正吃物理内存。进程状态S那一列也值得记一下R表示在运行或排队S表示可中断的休眠大多数进程的正常状态D表示不可中断的休眠正在等IO通常跟磁盘操作有关T表示已停止Z表示僵尸进程。如果你发现某个进程长期卡在D状态就要怀疑是不是磁盘出了问题这比单纯看wa数值更能直接定位到具体进程。3. 必会的键盘交互top不只是“看一看”3.1 排序切换P、M、N、T一键搞定很多人用top就是进来瞄一眼然后按q退出。其实top的交互能力非常强可以说是一个半图形化的监控终端学会这几个快捷键排查效率提升一大截。大写的P按CPU使用率排序大写的M按内存占用排序大写的N按进程号排序大写的T按累计CPU时间排序。默认进去是P排序也就是CPU最高的排最上面。我查看内存泄漏的时候习惯先按M看看哪个进程RES最大查高CPU问题就保持P排序一眼锁定“罪魁祸首”。如果你觉得默认的表头顺序看着不舒服可以按小写字母xtop会把当前排序依据的那一列高亮出来按b可以切换高亮颜色或者关闭颜色。再配合小写字母y可以把正在运行中的任务高亮出来。这几个键配合着按界面会清楚很多。3.2 实时操作杀掉进程、调整优先级顶部进程列表里如果发现了异常的进程可以直接在top里面处理。按k然后它会提示你输入PID回车后输入信号编号默认是15SIGTERM也就是温柔地请求进程退出。如果这个进程不听话你再按k输入PID信号编号填9SIGKILL强制杀死。回车后top会问“Send pid xxx signal [15]”这时候你再敲一次回车确认就行了。这里提醒一句k键杀进程要小心top默认会选中当前列表第一行的PID如果你没仔细看PID就连续回车回车可能把一个正在跑业务的进程给干掉了。我自己的习惯是杀进程前一定会把PID看两遍宁可慢也不能错。调整优先级用r键。它会让你输入PID然后输入新的nice值范围-20到19负数需要root权限。比如一个后台备份任务占CPU太高影响主业务了可以把它的nice值调高到10或者15让它“排队靠后”而不是直接杀掉。这种优雅降级的处理方式在运维里比一刀切杀进程更受欢迎。3.3 视图切换1展开多核、c看完整命令、f定制字段按数字1可以在“总计CPU”和“每个核心单独显示”之间切换。多核服务器上你特别需要这个功能因为有时候整体CPU不高但某个核已经打满了应用出现卡顿你要是只看总百分比根本发现不了这个问题。按c可以在“命令简称”和“完整命令行”之间切换。当你看到一行COMMAND显示成docker根本不知道是哪个容器按一下c完整路径和参数就露出来了信息量立刻不一样。按f进入字段管理界面。这里可以决定哪一列显示、哪一列隐藏上下键移动光标空格键切换显示状态。我把CPU列、内存列都留着把SHR和NI这些不常看的先隐藏掉省得屏幕太挤。调整好之后在字段管理界面按s可以把光标所在的字段设为排序字段按q退出。3.4 保存配置W键让设置“记下来”很多人不知道top的显示配置是可以持久化的。你调好了排序方式、隐藏了部分字段、切换了高亮按一个大写的Wtop会把当前配置写入用户目录下的.toprc文件。下次你再敲top界面就是你上次调好的样子。这个细节在批量运维很多服务器的时候特别有用只要在一台机器上调好配置把.toprc文件复制到其他机器上大家的top体验就完全一致了。4. top命令参数详解单次快照、指定进程、线程视图4.1 调整刷新频率-d参数top默认3秒刷新一次但我排查问题的时候觉得3秒太慢尤其CPU飙升这种场景恨不得一秒刷好几回。用-d参数可以自定义刷新间隔比如top -d 1就是1秒刷新一次top -d 0.5就是0.5秒刷新一次。反过来如果系统负载已经很高频繁刷新反而增加压力可以把间隔调大到5秒甚至10秒让监控过程对系统影响更小。4.2 只监控特定进程-p参数有时候你不想看整个系统只想盯住某个特定的进程比如某个Java服务、某个数据库进程。用-p参数加上PID就行。注意它支持多个PID用逗号分隔。比如top -p 1234,5678就只显示PID为1234和5678的两个进程。这个功能在盯一个已知的服务异常时特别好用没有其他进程干扰视线也能少消耗一点CPU去渲染那些无关紧要的列表。还有个更实用的组合top -H -p 1234。-H参数是开启线程模式也就是以线程为维度显示进程1234内部所有的线程。为什么要看线程因为一个Java进程或Go进程内部跑了几十个甚至上百个线程只有一个PID你要是只盯着%CPU知道进程CPU高却不知道是进程里哪个线程在作妖。用这个参数就能把问题精确到线程级别为下一步用jstack或者其他工具做线程栈分析铺路。4.3 批处理输出-b参数脚本自动化核心top终端交互模式适合人盯着看但如果你想定时抓一份数据存下来或者写脚本做自动化告警就得用批处理模式。-b表示batch modetop不再刷新屏幕而是像普通命令一样输出结果然后退出。通常配合-n参数使用-n 1表示输出一次就退出-n 10表示输出10次再退出。最常用的写法是top -b -n 1这一条命令会立刻输出一份完整的top结果你可以把它重定向到文件里保存top -b -n 1 snapshot.txt。然后配合cron定时任务每隔5分钟存一份快照出事以后就有历史数据可以翻。这个方法我在定位“半夜三点CPU莫名飙高”的问题时帮了大忙白天看到的结果和出问题时刻的数据往往完全不一样。注意一个细节top批处理模式下的第一次输出显示的CPU和内存数据是自启动以来的平均值不是瞬时值所以如果要做精确采样建议top -b -n 2并且取第二次的输出。第二次输出才是在你指定的时间点范围内的真实采样。4.4 其他实用参数-u、-o、-E、-s-u参数指定用户名比如top -u www只看www用户跑的进程。-o参数直接指定初始排序字段比如top -o %MEM一进去就按内存排序省得每次手动按M。-E参数切换内存显示单位可以写成-K指KB、-M指MB、-G指GB大内存机器上显示成GB更直观。-s参数是安全模式在安全模式下一些危险的交互命令会被禁用自己被root权限登录、又怕手滑误操作的时候加个-s至少心里踏实点。还有一个容易被忽略的-H参数前面说的配合-p用是看进程内线程其实-H单独用是让top默认以线程模式显示整个系统所有进程的所有线程。线程数量多的时候会刷屏谨慎使用。5. 关键指标深挖负载、CPU状态与内存的三重门道5.1 load average看懂趋势比看懂数字更重要很多人把load average和CPU使用率当成一回事这是理解top的头号误区。CPU使用率描述的是“CPU有多忙”而load average描述的是“有多少任务在等着被处理”。打个比方CPU使用率相当于收银员的工作饱和度load相当于排队的顾客人数。顾客多不一定代表收银员忙也可能是收银速度慢或者某个顾客卡住了。load average第一个数字是1分钟平均值第二个是5分钟第三个是15分钟。三个数字一起看能看出负载走向如果1分钟 5分钟 15分钟说明负载正在上升系统开始吃紧如果反过来说明高峰期在消退。我用这个趋势判断要不要马上介入处理比单看一个瞬间值要有价值得多。负载多少算高不是看绝对数字是除以CPU核心数。比如8核机器load到8相当于8个核都排满了开始有任务等待load到4还算健康区间。我自己的经验阈值是长期超过核心数的0.7倍就要警惕超过1倍就要着手处理了。当然这只是经验值不同业务类型对延迟的敏感度不同数据库这类服务对负载会更敏感。5.2 CPU状态us、sy、wa、st这些字母背后的线索CPU那行八个状态值普通人只扫一眼id空闲和us用户态但真正的线索往往藏在其他几个值里。us高说明用户程序在耗尽CPU典型场景是死循环、密集计算、正则回溯爆炸sy高说明内核在频繁干活常见原因是系统调用过多、上下文切换太频繁、网络包处理量大。如果你看到sy超过30%最先怀疑的应该是是不是有程序在疯狂创建线程或者发起系统调用可以用perf或者strace进一步确认。wa高是最容易被误判成“CPU忙”的状态其实wa表示CPU在等待IO完成CPU本身其实是闲着的被卡住了。wa高的时候你看us和sy通常不高进程状态里可能有一堆D状态的进程。这时候该查的是磁盘、网络IO而不是去加CPU核数。我处理过一次数据库变慢的问题top里wa超过40%最后定位到是磁盘快满了导致IO性能断崖式下跌加CPU根本没用。st是虚拟机特有的一列。如果你跑在云服务器上st长期偏高说明宿主机资源超卖严重你的CPU时间被其他虚拟机抢走了这个层面的问题你在自己机器里查不出个所以然来因为物理硬件资源有限跟你的邻居有关。top帮你看出来问题是第一步“被偷走”的原因要去平台侧确认。5.3 内存与交换分区used大不代表内存不够Linux内存管理和Windows思路不太一样。Linux会尽量利用空闲内存做文件缓存buff/cache这是为了加速磁盘读写所以你会发现top里free那列数值很小但系统运行很流畅这是正常现象不是内存泄漏。判断内存够不够标准姿势是看avail Mem这一列。它不是简单的free缓存而是内核估算的、在不触发交换的情况下还能分给进程的内存量。只要avail Mem还比较富余哪怕used看起来很高也不用太恐慌。看Swap列有个细节要注意swap的used大并不一定代表内存压力大有可能只是某些进程被换出去之后一直没回来而系统内存后来也富裕了但已经被换出的页不会自动换回。判断内存压力的核心指标其实是si和so。在top界面上要看这两个值通常得在f字段管理里把si和so这两列调出来或者用vmstat。si表示换入swap inso表示换出swap out这两个数值如果持续不为0说明内存真的不够用了系统在频繁倒腾内存页性能会大幅下降。5.4 进程生命周期僵尸进程和孤儿进程的真相进程状态Z僵尸是很多新手恐惧的对象。所谓僵尸进程就是进程已经结束了但它的退出状态没有被父进程读取占着进程表里的一个位子不肯走。僵尸进程不消耗CPU也不消耗内存但占着PID如果大量累积会导致新的进程无法创建。top里看到Z状态第一步要找到它的父进程是谁。可以用ps -ef | grep defunct找到僵尸进程的PPID然后看那个父进程是不是还活着如果父进程还活着去看看它是不是没有调用wait系统调用收尸。通常解决办法是重启父进程或者让父进程处理完子进程的退出状态。如果父进程也已经死了僵尸进程会被init进程接管init过一会儿就会把它们清理掉不用太担心。6. top玩出花批量快照与自动化监控脚本6.1 定时快照采集把top变成数据采集器生产环境不可能24小时有个人盯着屏幕监控自动化才是正路。最简单可靠的办法就是cron加top批处理模式。我常用的一个做法是在cron里加一条每分钟任务* * * * * cd /var/log/top_history top -b -n 1 | head -n 25 top_$(date \%Y\%m\%d_\%H\%M\%S).log这样每分钟生成一份top快照文件列出系统概况和前20来个进程。半夜系统出问题第二天早上查文件几点几分什么进程CPU高、内存状态什么样一目了然。配合日志轮转避免文件堆积用logrotate就能实现。6.2 提取关键数据grep和awk配合使用直接存整个top输出当然可以但文件多了会膨胀而且不便于后续统计。更好的方式是用管道把关键行提取出来。比如只要系统概况和CPU那几行top -b -n 1 | head -n 5再比如只要某几个特定进程的信息top -b -n 1 | grep -E PID|java|nginx写脚本做阈值告警时可以用awk解析。比如抓取内存可用量低于某个值时发出告警top -b -n 2 -d 1 | grep KiB Mem | tail -n 1 | awk {print $NF}这里取$NF也就是最后一列正好是avail Mem。用tail -n 1是为了拿第二次采样的结果避开top第一次输出的平均值问题。6.3 一个完整的CPU告警脚本示例我把这些技巧拼成一个简单的告警脚本当CPU空闲率低于20%时输出告警。这个脚本可以放在cron里执行也可以丢到监控平台上做自定义检查项。#!/bin/bash THRESHOLD80 CPU_USAGE$(top -b -n 2 -d 1 | grep Cpu(s) | awk {print $2} | cut -d% -f1 | tail -n 1) IS_USAGE$(echo $CPU_USAGE $THRESHOLD | bc) if [ $IS_USAGE -eq 1 ]; then echo $(date) CPU usage high: ${CPU_USAGE}% /var/log/top_alert.log # 实际环境里可以在这里触发企业微信、钉钉、短信等告警通道 fi简单说明一下top -b -n 2 -d 1表示每1秒采样一次、共采2次grep Cpu(s)拿到CPU那一行awk {print $2}取出us那一列cut去掉百分号tail -n 1确保取的是第二次采样的结果。bc用来做浮点数比较因为CPU使用率是带小数的。这个脚本是一个模板你可以把它扩展成监控内存、监控某个进程的CPU占用、监控load average等多种场景核心思路都是一样的。灵活运用你需要的场景朝着需要的方向去修改grep和awk的提取逻辑就行。6.4 清理历史数据别让监控日志成为新的故障源自动化监控最容易被忽略的就是日志维护。你每分钟存一份top快照一个文件几KB一天下来也有十兆左右一两个月不清理就能堆满一个小磁盘分区。磁盘满了之后第一个遭殃的可能就是写日志的程序本身。我就在现场见过监控脚本因为日志没清理把磁盘写满最后数据库都起不来了属于典型的“监控把自己监控死了”。处理方式有两种简单点的是给cron任务加一条find清理命令find /var/log/top_history -type f -mtime 7 -delete复杂点的是用logrotate配置轮转设置保留周期和压缩。我个人建议用logrotate它更规范压缩之后还能省不少空间。7. 实战演练从CPU飙高到定位问题线程的完整链路7.1 第一步top确认异常现象假设现在线上一个Java服务响应很慢登上去执行top看到这样一个画面PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 3456 app 20 0 5486924 1.2g 13256 R 198.0 15.3 123:45.67 javaPID 3456这个Java进程CPU 198%几乎占满了两个核这大概率是问题的源头。但到这里只是万里长征第一步要知道为什么它会占这么高光有PID不够。7.2 第二步进入线程视图定位热点线程执行top -H -p 3456这时候显示的不再是进程列表而是这个Java进程内部所有线程的列表。同样按P按CPU排序会看到某个线程的TID排在最上面比如TID是5678CPU占用可能是120%。这里有个关键点我们的目标是找出这个线程在执行什么代码。对于Java应用下一步要把这个线程ID转成十六进制因为jstack输出的线程nid就是十六进制格式。printf %x\n 5678得到0x162e。然后用jstack抓线程栈jstack 3456 /tmp/thread_dump.txt grep -A 30 0x162e /tmp/thread_dump.txt在输出里你会看到这个线程正在执行的Java方法栈从框架代码到业务代码一层层列出来。往下翻几层就能看到具体的业务代码行号问题基本就定位到了。7.3 第三步结合其他工具做进一步确认线程栈只能告诉你CPU时间花在哪个方法上如果想进一步确认是不是垃圾回收频繁导致可以用jstat -gcutil 3456 1000看GC曲线如果怀疑是某个锁导致的线程竞争可以再抓两三次线程dump看看热点线程是否卡在同一个锁对象上。top的使命到这里就完成了它是整个排查链条的起点帮你在最短时间内缩小了范围。如果排查的是非Java进程比如一个C程序第二步的线程ID同样有用可以用gdb attach上去也可以用perf top -p 3456直接做CPU采样看最热的函数是哪个。7.4 实战心得top快照的“证据意识”我在处理线上问题时习惯先把top -H -p的线程快照存一份文件再动手做任何操作。因为一旦你重启进程、修改配置、压测复现现场就被破坏了再想回溯就得靠这份快照。有经验的排查人员都会先采集证据再动手这个习惯能帮你少走很多弯路。8. 常见问题与避坑手册这些坑我全都踩过8.1 CPU明明高却找不到高占用进程场景top界面一眼扫过去%CPU最高的进程也只有3%但Cpu(s)那行显示us高达70%。这种现象通常有三个原因。第一进程在频繁地启动和退出比如cron任务、短生命周期脚本你看到top的那一瞬间它“正好下班了”。解决方案是抓取一段时间top -b -n 5 -d 1把多次结果放一起对比或者用pidstat跟踪一段时间内的累计CPU。第二CPU消耗在内核态比如某个驱动存在问题或者网络包异常sy那行会特别高你需要用perf去采样内核栈。第三进程被固定在某个CPU核心上而top默认显示的是进程总体CPU使用率你按1展开多个核看看是不是某个核已经打满、但进程的总占用被摊薄了。8.2 僵尸进程出现后怎么处理才有效看到Z状态的进程先别急着kill。僵尸进程已经是死掉的状态kill对它没有意义。先看它的父进程是谁ps -ef | grep defunct然后判断父进程是否正常。如果父进程是业务进程检查它是不是有bug没有正确调用wait族函数来回收子进程。如果是你自己的小程序写代码时用信号处理器或者让父进程调用waitpid就能从根上解决问题。线上最快速的处理办法是重启父进程让新的父进程接管并清理遗留的僵尸。8.3 top显示的内存used巨大但业务实际占用并不高原因大概率在buff/cache占用过多。Linux的缓存策略是把空闲内存拿来做缓存甚至包括文件页缓存、目录项缓存。在top界面上你会看到used那一列很大free那一列很小容易误判为内存不足。正确的判断口径是用avail Mem它估算的是包括可回收缓存在内的可用内存。假如avail Mem还很充裕就不需要处理如果确实紧张也不建议手动回收缓存而是排查哪个业务进程在大量申请内存。8.4 top刷个不停抓取日志怎么处理手动复制top输出到文件的时候屏幕刷新导致内容一闪而过很难操作。直接用批处理模式解决top -b -n 1 snapshot.txt或者配合grep过滤关键行。想要持续记录一段时间的滚动态势可以top -b -n 30 -d 1 history.txt这里的-n和-d组合在批处理模式下非常实用。8.5 误按k键差点杀掉进程的经历top的k键交互设计有一个比较刺激的地方你按k后默认PID是当前列表第一行那个进程很多次你只是想按一下看看效果回车回车就把一个飞快刷新的进程给终止了。建议是普通操作的时候不要轻易按k真要按先确认PID是你想操作的那个信号编号也看清15和9的区别很大。15是温和地请求退出9是强制终结两者之间最好有个明确的判断过程。如果不想冒风险加-s安全模式里面的k和r这类修改操作会被禁用。8.6 top数据是平均值怎么读得更准top第一次显示的数据有“历史包袱”%CPU计算的是自上次刷新以来的CPU时间增量除以刷新时间批处理模式下第一次输出可能不够精确。所以在做自动化采集时我习惯采两次取第二次。手动观察时尽量多盯几次刷新不要因为第一次看到的数值就下结论。尤其是负载和CPU这类动态指标至少要观察5秒以上再下结论只看一瞬间容易误判。9. 我的使用习惯和top的边界最后说说我自己的习惯。排查问题的时候top是我的第一站但绝不是终点。top擅长给你一张全景图负面信息一目了然但要深挖原因需要组合使用ps、ss、lsof、jstack、perf、strace、iostat这些工具。比如top看到wa高接着用iostat看具体哪块磁盘卡看到某个进程网络占用异常配合ss看连接数看到Java进程CPU高用jstack定位代码行号。没有top打底这些后续操作都没有方向。另一个平时很容易忽略的功能是top的字段定制。通过f键把需要的字段列出来把无关的隐藏比如加上%CPU的“平均上一次刷新”列或者把进程的累计CPU时间TIME列出来可以帮助区分“这个进程一直吃CPU”还是“最近才开始吃CPU”。TIME很小但%CPU很大的进程往往是刚启动就出问题的新进程TIME很大但%CPU很小的进程只是活的久别被它迷惑。top这个命令看起来简单实际上是Linux系统性能观测的基石。你越熟悉它排查问题就越有底气。以后遇到系统变慢的情况不妨先按我建议的顺序走一遍先看load趋势再看CPU和内存概况找一个异常的进程然后用-H看线程最后结合其他工具定位根因。这套流程走下来绝大多数性能问题都能找到方向剩下的就交给经验积累了。
