面试讲到Linux排查，十个有八个会先说top看一眼负载，然后再背一串命令参数。但聊到"你上次线上出问题是怎么一步步定位的"，很多人就开始含糊了。其实面试官想听的从来不是"我会用哪些命令"，而是"你遇到问题时，用什么逻辑把这条命令用起来"。这篇就把8个一定会用到的命令，按真实排障的顺序拆开讲——每个命令配一个高频故障场景，讲清楚你看到了什么、接下来该查什么、面试时怎么把这套思路说清楚。这套内容不是我临时拼的，是我把这些年处理过的线上问题、带人时反复强调的排查套路，浓缩成了一张可以照着练的地图。
1. 先把排障的底层逻辑理顺：面试和实战共用一套"三层定位法"
在展开8个命令之前，先把最重要的东西放前面：Linux排障不是"命令的堆砌"，而是一条有方向的链路。面试官真正考察的，是你面对一个模糊现象时，能不能快速缩小范围、判断方向、找到根因。
我习惯把排查过程分成三层：现象层、资源层、根因层。
- 现象层：用户说"系统变慢了""接口超时了""服务挂了"，这是最原始的信号，基本不可信，需要量化。
- 资源层：通过命令确认瓶颈在哪——CPU、内存、磁盘、网络、文件句柄，这层解决"哪里出了问题"。
- 根因层：根据资源层的线索，进一步定位是什么进程、什么连接、什么日志导致的，这层解决"为什么出问题"。
8个命令正好覆盖这三个层次。top、free、df/du、iostat是资源层的四大件；ss、ps、lsof往根因层深入；dmesg和journalctl属于证据链，用来验证你的判断。整套逻辑可以简化为四句话：先看负载和饱和度，再看瓶颈资源，顺藤摸瓜找到进程，最后用日志验证结论。
面试时最能体现水平的一句话是："我会先用top确认系统整体状态，如果CPU或负载异常，再用ps和top的进程视图定位到具体进程，最后用日志佐证。如果CPU正常，我会转而看内存、IO或网络。"这段话一句话就把三层定位法说完了，比背十个命令参数有用得多。
实战中还有一个容易被忽略的点：先确认时间范围。问题是什么时候开始的？是持续性的还是偶发的？有没有伴随发布变更？这些信息决定了你排查的优先级。很多人一上来就敲命令，结果查了半天发现问题是昨天上线的新版本引入的——白忙一场。我自己的习惯是先问一句"最近有没有动过什么"，再开始看数据。
接下来按排障时真正会碰到的顺序，把这8个命令一个一个讲透。
2. top：所有性能问题的第一块屏幕，CPU和负载的真相都在这里
top属于第一个要敲的命令。不是因为别的，因为它能把系统整体状态一次性摆在你面前——负载、CPU使用率、内存、进程列表全都有。它能回答两个关键问题：系统整体的压力大不大？压力主要落在哪里？
先说负载（load average）。top第一行有三个数字，比如load average: 0.35, 0.20, 0.10，分别代表1分钟、5分钟、15分钟的平均负载。很多人以为负载高就是CPU忙，其实负载是"正在运行"加"不可中断睡眠"的进程数量总和，不是一个百分比。判断负载是否异常，最实用的口径是拿它和CPU核数比：负载长期大于核数，说明任务在排队；负载小于核数，即使数字看起来很大，通常也没那么严重。比如8核机器load到7并不算爆炸，2核机器load到7就基本卡的没法看了。
再看CPU状态行，那一排us sy ni id wa hi si st是面试高频考点。排障时重点看两个比值：us（用户态）和sy（内核态）。如果us高，说明是应用业务代码在抢CPU，要往进程层查；如果sy高，说明系统调用和内核处理消耗了大量CPU，常见原因是频繁的上下文切换、系统调用过多或者IO中断风暴。
我遇到过最典型的案例是这样的：某服务的接口大面积变慢，top一看CPU的sy到了70%，us才15%。第一反应不是查应用代码，而是看进程数和上下文切换。top里按C键可以看到进程CPU的细分耗时，用pidstat -w能看到每秒上下文切换次数，一查发现某个进程的线程数异常膨胀，几千个线程在疯狂争抢锁——问题根源是代码里出现的死循环导致线程池被打满。如果只看us高就一头扎进业务逻辑，很可能绕远路。
实操时几个最常用的交互键记牢：P按CPU排序、M按内存排序、1展开每个核的使用率、c显示完整命令行、e切换内存显示单位。线上环境我最常用的动作是打开top后先按1确认是不是单核打满、其他核空闲，这种"单核瓶颈"在负载不高但业务卡顿的场景里非常常见——很多老程序是单线程的，核再多也只能用一个。
面试话术参考：
我一般先跑top，重点看load average和us/sy的比值。如果load持续大于核数，说明系统整体过载；如果sy异常高，我会怀疑上下文切换或内核态开销过大，然后用pidstat看切换次数，进一步定位到具体进程和线程。如果us高，就直接按CPU排序锁定进程。
这里有个容易被面试官追问的点：为什么load average高不等于CPU高？答案是负载统计包含了不可中断睡眠（通常是等待IO），所以"高负载+低CPU"大概率是磁盘IO瓶颈——这句话一出来，面试官就知道你不是死记硬背的。
3. free：内存明明"没满"，服务却被OOM Kill，问题出在available
free太常见了，常见到很多人用它只是看一眼数字而已。但内存排查里最大的误区恰恰就藏在这里：以为free那一列是剩余内存。
现在的系统里，free -h输出的free列是"完全没有被使用"的内存，而真正反映可用程度的是available列。因为Linux内核会把空闲内存拿来当缓存（buff/cache），这些内存在需要时可以回收给应用程序用，所以available才是"在不触发交换的情况下，还能新分配给进程的内存"的估算值。你看free只有几百MB，但如果buff/cache占了几个G，available也还有几个G，系统其实没到危险线。
我踩过一个特别典型的坑。某托管的数据库实例在凌晨突然被操作系统杀掉，报警记录写着OOM Kill，监控面板显示内存使用率明明只有70%。查了半天发现，监控脚本取的是free的百分比，但实际available已经跌倒只剩200MB了。为什么？因为那个时段有其他批处理任务在疯狂申请内存，把缓存全挤掉了，而监控没看available，所以根本没有提前预警。从那以后，我任何内存监控指标都强制用available，不再看free。
排查内存问题的完整链路是这样的：先free -h看整体水位和swap使用情况，如果swap使用量在持续增长，说明内存已经在吃紧了。然后切到top按M排序，找到占用RES最高的进程。RES是常驻物理内存，VIRT是虚拟内存，排障以RES为准，因为虚拟内存基本是"账面上的空间"。
还要注意一个细节：cgroup限制下的容器。在Docker或K8s环境里，free看到的是宿主机的整体内存，不是容器能用的配额。判断容器内存状态应该看cat /sys/fs/cgroup/memory/memory.usage_in_bytes，或者直接用docker stats。很多人在容器里看到free还剩一大半，但应用一直OOM，就是因为容器限额早到了，只是宿主机层面看不出来。
面试话术参考：
我会先看free的available，而不是free列。available真正反映了系统还能分配多少内存给新进程。如果available很低、swap换入换出频繁，说明内存压力大，再用top按内存排序定位进程。如果进程RES不高但系统仍OOM，我会检查页表开销和内核slab内存，这种情况常见于大量小文件缓存。
面试官追问"buff/cache能不能直接清掉再用"时，可以说echo 3 > /proc/sys/vm/drop_caches能清缓存，但这只是缓解手段，不是解决手段——缓存清了应用程序内存仍然不足时照样会OOM。这句话能体现你不是只会"抄命令"的人。
4. df / du：磁盘满了却找不到大文件，99%是"删了但没释放"的坑
磁盘排查，一对命令就够了：df看文件系统整体使用率，du看具体目录和文件占用。但真实场景里最经典的故障是：df -h显示/已经100%，但用du -sh一层层看下去，加起来根本对不上那一百多G。
我第一次遇到时也懵了很久。逻辑上文件都被删了，为什么磁盘还是满的？答案是：有进程仍然持有已被删除文件的文件句柄。Linux里，文件被unlink后，只要还有进程打开着它，磁盘空间就不会真正释放——直到那个进程把文件关掉或者退出。日志文件、临时文件、数据库的binlog都容易踩这个坑。
排查命令是lsof | grep deleted。找到那些带着deleted标记但还开着的文件，看PID，然后判断是重启进程还是优雅地通知应用重新打开日志句柄。这里有个经验之谈：du -sh在超大目录上会跑很久，可以先从df的挂载点入手，用du -sh /下面一级的目录一层层查，用du --max-depth=1 -h一次列出当前目录下所有子目录的大小，更快地锁定大头。
还有一种"百分比对不上"的原因：df统计的是文件系统块的使用，里面包含了保留块（默认5%，给root用的应急空间）和元数据开销，而du统计的是文件内容字节数，口径本来就不同。所以du加起来比df少5%-10%是正常的，差得离谱才要怀疑deleted句柄。
另一个高频场景是inode耗尽。df -h显示还有50%空间，但应用报"No space left on device"，八成是/的inode用完了，因为Linux下每个文件都要占用一个inode，小文件特别多的时候，空间没满但inode先满了。这时候要跑df -i确认，再用find / -xdev -type f | wc -l估算文件数量，重点排查临时目录、缓存目录和邮件队列。
面试话术参考：
磁盘排查我会先df -h看使用率，然后du逐层定位大文件。如果df显示满但du加总对不上，我第一反应是查lsof里deleted状态的文件，这种情况是进程还占着已删除文件的句柄。另外我会用df -i检查inode，避免因为小文件太多导致inode耗尽。
这一段话同时覆盖了两个易错点：deleted句柄和inode，能直接拉开和其他候选人的差距。
5. iostat：数据库慢、接口响应慢，但CPU和内存都正常——IO才是真凶
有些故障表现得很奇怪：CPU不高、内存充足、负载不高，但应用就是慢。这时候把注意力从CPU和内存转走，去看磁盘IO，大概率能发现真相。iostat -x 1就是干这个的，它按每秒刷新一次的方式来观察磁盘的实时状态。
重点看两个指标：%util和await。%util在传统机械盘上接近100%说明磁盘已经忙不过来，但在SSD上这个指标经常会虚高，因为SSD的并行处理能力和机械盘不是一个逻辑，所以不要只凭%util下结论，要结合await（平均IO请求处理时长）一起看。如果await只有个位数毫秒，即使%util到90%，磁盘其实也不慢；反过来，await持续几十上百毫秒，那才说明IO确实在拖后腿。
iostat给出的是整个磁盘的聚合指标，定位到具体进程还需要工具配合。iotop能直接看到哪些进程在读写磁盘——这命令在排障时的价值极高，一条iotop -o就能把正在做IO的进程列出来。还有pidstat -d可以按进程维度看IO读写速率，不需要额外装工具。
我处理过一个很典型的案例：某服务每天晚上定时任务一跑，线上接口就集体变慢。CPU和内存指标完全正常，但用iostat -x 1一看，%util持续98%，await从3ms涨到80ms。用iotop锁定到有批处理进程在大量随机读写——最后发现是定时任务在扫全表，造成大量随机读，把同一块盘上的主业务IO给拖垮了。这就是典型的"IO饱和导致应用卡顿"场景。
还有个面试必考的细节：写日志引发的IO问题。应用把大量日志写到磁盘，尤其是使用了fsync同步落盘（数据库、消息队列常见），每一个小请求都要等磁盘真正写完才返回，延迟自然就高了。这种情况iostat上的await可能正常，但w_await（写延迟）会异常高，应用平均延迟和w_await几乎是线性关系。
面试话术参考：
CPU和内存正常但服务慢时，我会看iostat -x。重点关注%util和await：如果%util高但await很低，说明磁盘本身能处理，要查是读多还是写多、是随机还是顺序；如果await涨到几十毫秒，基本坐实了磁盘IO瓶颈。再用iotop定位到具体进程，排查是不是有大查询、全表扫描或者频繁fsync的日志写入。
这里体现出的是"区分瓶颈类型"的能力——同样是磁盘慢，随机读写、同步写、容量饱和造成的慢，处理方式完全不同。
6. ss / netstat：TIME_WAIT堆积到几万，不是调一下内核参数就完事
网络排查这块，面试几乎必问的就是TIME_WAIT。很多人的回答是"用netstat数TIME_WAIT，然后改内核参数调低timeout"，这个回答只能说及格，但离"能干活"还有距离。
先说命令本身：netstat -ant能列出所有连接状态，ss -ant是它的升级版，因为ss直接读内核socket信息，速度快、输出更全，不像netstat在一些高连接数场景下会慢得让人着急。日常排查我基本只用ss。先跑ss -s看整体统计——系统当前有多少连接、多少处于TIME_WAIT状态——这个命令一行就能给出全局数字，不用翻列表慢慢数。
TIME_WAIT这个状态是TCP四次挥手的产物：主动关闭连接的一方，收到对方的FIN并回复ACK后，会进入TIME_WAIT，等待2MSL（通常60秒）后才彻底关闭。它的存在是为了防止旧连接的报文残留在网络里干扰新连接。所以TIME_WAIT在一定数量内是正常的，每个主动关闭的连接都会产生一个，关键看量级和增长速度。
问题场景通常是高并发的短连接服务：每次请求都新建连接，用完后主动断开，服务器上就会出现大量TIME_WAIT。我见过最多的一个案例，连接数直接冲到5万多，导致新连接出现偶发失败。但这里要讲清楚：TIME_WAIT本身不占用太多内存，真正出问题是当它多到把本地端口范围耗尽（默认通常是32768到60999），或者连接表项过多影响性能时。
很多人第一反应是调net.ipv4.tcp_tw_reuse和tcp_tw_recycle。这里有个大坑：tcp_tw_recycle在NAT环境下（几乎所有云平台都是）会带来严重问题，它会因为时间戳校验不通过而丢弃来自同一个NAT出口的某些新连接，导致服务间歇性访问失败。这个参数我已经很久不碰了。更稳妥的方向是：减少主动断开（用连接池复用连接）、增加端口范围、打开tcp_tw_reuse配合tcp_timestamps，以及确保keepalive合理设置。
排查时还要区分另一类连接状态异常：SYN_SENT堆积说明对端不响应（可能是网络问题或对端满载）；ESTABLISHED异常多但连接不活跃，要怀疑连接泄漏，这时配合lsof查具体进程的fd数。这些状态词都要能脱口而出，面试才聊得下去。
面试话术参考：
网络排查我会先ss -s看整体连接状态统计。如果TIME_WAIT大量堆积，先确认服务是主动关闭方、短连接场景，再检查本地端口是否耗尽。解决思路是优先用连接池和长连接复用，避免频繁建连断连，其次再考虑端口范围和tcp_tw_reuse等内核参数。我不会盲目开tcp_tw_recycle，因为NAT环境下容易引发更奇怪的问题。
这段话的含金量在于，既说清了现象和影响，又给出了分层处理思路，还展示了对坑的了解。
7. ps：排查进程时最容易翻车的三个误区——VSZ、RSS、僵尸和容器
ps大概是所有人最早学会的命令之一，但恰恰是这种"太熟悉"的命令，最容易在细节上翻车。ps aux的输出里，%CPU是按单核百分比算的，不是说数值超过100就意味着异常——多核进程完全可以在top里显示300%、400%的CPU占用。还有VSZ和RSS这两个字段，VSZ是虚拟内存大小，RSS是物理内存占用，排障时只能信RSS——很多程序因为内存映射的机制，VSZ能显示到几十个G，但实际物理内存没占那么多。
排查进程异常时的动作顺序是这样的：先top -p PID锁定单个进程，然后ps -p PID -o pid,ppid,user,stat,%cpu,%mem,rss,vsz,etime,cmd --sort=-%cpu一步到位看完整信息。STAT状态栏是重点，进程状态里大写D表示不可中断睡眠（通常是等IO）、R运行中、S睡眠、Z僵尸。看到Z就要小心了——僵尸进程是父进程没调用wait回收，已经死了但没被清理掉的子进程。单个僵尸进程不可怕，可怕的是它堆积，通常说明父进程本身出了问题，处理办法是找到父进程确认它的状态，恢复父进程的健康后僵尸自然被回收，硬杀僵尸是杀不掉的（因为它已经不是活进程了，信号对它无效）。
容器场景下还有个经典坑：很多精简的基础镜像里没有ps完整字段的实现。你在容器里执行ps aux，有时候%CPU和%MEM全是0，或者COMMAND列显示不完整。这不是系统出问题了，是镜像里的ps工具不全。标准做法是用宿主机的top -p查容器的PID，或者用docker stats看资源占用，然后把/proc/<pid>/下的信息当真相源。
ps配合/proc深入的时候，玩法就多了。比如cat /proc/PID/status能看线程数、内存详情、上下文切换次数；ls /proc/PID/fd | wc -l能统计这个进程打开了多少文件句柄——这两个命令在排查线程泄漏和文件句柄泄漏时是决定性的证据。面试能主动提出来，属于明显的加分项。
面试话术参考：
我的经验是用ps时重点看RSS而不是VSZ，然后结合STAT字段的状态判断进程是否健康。出现僵尸进程时我第一反应是找父进程而不是处理僵尸本身。容器环境里我会意识到ps工具可能不完整，直接在宿主机用top加-p参数或者查/proc来确认真实资源占用。
这里体现了三个层级的认知：基本字段含义、状态机理解、容器场景差异，每一层都能接住追问。
8. lsof：文件句柄泄漏，面试里最容易被追问到"讲不下去"的话题
lsof可能不是最常用的命令，但一旦系统出现"too many open files"报错，它就是主角。文件句柄泄漏在Java应用、数据库连接池、消息队列客户端里都很常见，面试聊这个话题基本能探出候选人到底有没有真正遇过线上故障。
先说文件句柄的底层逻辑：Linux里一切皆文件——普通文件、目录、socket、管道都是文件描述符，进程每打开一个，就要占一个fd。系统有上限，进程也有上限，通过ulimit -n查看。默认1024这个老数值在现在的应用负载下经常不够用，很多高并发服务上线前就该调高。
排查链路是这样的：应用报too many open files，先ulimit -n确认软限制和硬限制，再看进程实际打开的数量ls /proc/PID/fd | wc -l。如果接近上限，基本坐实句柄快耗尽了。这时候lsof -p PID列出所有打开的fd——注意fd数字每一个对应一个具体对象：cwd当前目录、txt程序文件、mem内存映射，以及一堆socket、pipe、REG（普通文件）。
最经典的泄漏场景，一是日志文件反复打开不关闭，二是连接池回收逻辑缺陷导致socket一直建立不释放，三是临时文件创建后忘记删除。排查时lsof -p PID | grep deleted能看到已经被删除但仍被占用的文件，lsof -p PID | grep TCP能看到这个进程建立的连接——如果连接数异常多但实际活跃连接很少，说明连接在泄漏而非正常复用。定位到具体是哪个句柄在涨之后，修复方向就清晰了：重启进程是临时止血，修复代码是长期方案。
聊句柄的话题时还有个重要概念：每个TCP连接也是一个文件句柄。所以句柄泄漏和上一章说的连接泄漏是同一个问题的一体两面。很多"连接数暴涨"的故障，表面是网络问题，本质就是文件句柄耗尽。面试能把这个关联讲清楚，说明你对进程、文件、网络三个概念的理解是打通了的。
面试话术参考：
遇到too many open files，我会先确认进程句柄上限和当前用量，用lsof -p PID看具体打开的文件和socket类型。出现deleted文件或大量TCP连接持续上涨，基本就是泄漏。处理分两步：先临时扩大上限并重启恢复服务，再根据lsof定位的泄漏点去排查代码，比如日志文件未关闭、连接池回收异常这些原因。
这句话的精髓在于，"临时止血"和"长期修复"分得很清楚，不会出现只重启不根治的局面。
9. dmesg / journalctl：前7个命令负责定位，这两个负责"验证定罪"
排查到最后一公里，必须有日志来验证你的判断，否则前面的推测都只是"高度怀疑"。dmesg专门看内核环形缓冲区里的消息：OOM Kill记录、硬件报错、网络栈异常、文件系统错误，全都写在里面。比如你怀疑某进程是被OS杀的，dmesg -T | grep -i oom直接就能看到内核在哪个时间点杀掉了哪个进程，顺便还能看到当时的内存统计——这是无可辩驳的证据。
journalctl则是systemd环境下查看应用和系统服务日志的门户。journalctl -u service-name看某个服务单元的全部日志；journalctl -f实时跟踪新日志；journalctl -k -b查看本次启动的内核日志；journalctl --since "30 minutes ago"按时间过滤。排障时最高效的使用方式是：先定位到报错的时间窗口（比如用户反馈"下午3点开始卡"），然后用journalctl --since把日志拉到那个时间段，再grep关键字慢慢收窄。
一个完整的案例复盘是这样的：某服务在凌晨出现无响应，用top看到负载和CPU都不高，接着看free发现available骤降，怀疑内存压力，然后用dmesg -T | grep -i oom一查，果然看到内核在凌晨3:17杀掉了某个Java进程，还记录了当时的内存快照。再切到journalctl -u app-service --since "03:15" --until "03:20"，能看到被杀之前应用打的最后几行日志——最后定位是GC线程触发了疯狂内存分配，和定时任务撞在一起。整套证据链完整闭合，从现象到资源到根因全部串上，没有任何猜测成分。
这是面试里的"收尾能力"展示。很多人能说到"我怀疑是OOM"，但说不出"我通过dmesg确认了OOM的发生时间和进程，然后用journalctl还原了当时的应用日志"。一字之差，水平完全不同——前者是猜，后者是验证。
面试话术参考：
定位到最后，我会用dmesg和journalctl收口。dmesg查内核层面的OOM和硬件错误，journalctl按时间窗口回放应用日志。比如怀疑OOM，dmesg -T能明确看到被杀进程和触发时间，日志能还原当时的业务上下文，这样整个排查链路就有了闭环。
10. 把8个命令串成一场完整排障：从报警到根因的40分钟实战复盘
最后用一个完整案例把这8个命令的协作方式演示一遍。某天上午10:20，监控报警：某服务的P95延迟从80ms涨到3秒，错误率4%。我接到报警后没有急着敲命令，先确认了时间窗口和是否近期有变更——同事昨晚上线了一个查询接口的优化逻辑，这个信息记录在案。
10:22，第一轮：现象量化。top一看，load average约在3.5，而这是台4核机器，负载偏高但没到爆炸，us25%、sy15%，还有余量。CPU没有完全饱和，但延迟已经很高了，所以CPU不是瓶颈。
10:25，第二轮：内存排查。free -h显示available还有3G多，内存充足，swap没动静，排除内存问题。这里有个心得：内存问题通常是慢慢恶化的，很少会在几分钟内把可用内存从几G耗尽到0，如果出现这种斜率，先怀疑内存泄漏程序，但本案没有这个特征。
10:28，第三轮：IO排查。iostat -x 1刷了三遍，%util在45%上下波动，await不到5ms——磁盘也没有瓶颈。
CPU、内存、磁盘都正常，那问题在哪？此时回头重新审视top的输出，发现在进程列表里有一个python进程的%CPU只有5%，但它的状态是D（不可中断睡眠）。一个D状态进程不算多，但配合刚才"CPU没满、延迟高"的现象，我开始怀疑锁竞争或上下文切换。
10:32，深入进程层。pidstat -w 1一看，每秒上下文切换高达8万次，其中大部分来自那个查询接口的Java进程。再top -H -p PID看它的线程，能看到若干线程在反复切换。这一步把范围从CPU问题缩小到了线程调度异常。
10:36，验证阶段。查这个Java进程的日志，journalctl加时间窗口回放，看到大量"获取分布式锁超时"的警告。往前翻代码变更记录，昨晚上线的优化里加入了一大段循环内频繁访问Redis的操作，而且是单连接、同步模式，每个请求要等Redis返回才能继续，等于人为制造了线程阻塞和上下文切换风暴。回滚了那个变更后，10:50延迟恢复到80ms。
这个案例最值得记住的一点是：真正导致问题的不是某种资源打满，而是资源使用方式的低效。如果只盯着"哪里满了"来排查，很可能绕一大圈找不到根因。top、free、iostat告诉你"没满"，不代表"没问题"——它们只是缩小范围，而ps、pidstat、journalctl负责在"没满"的范围内找到异常行为。8个命令是一套组合拳，少了任何一环，排查链路都会断。
11. 最后再分享三个实在的经验
说完8个命令和整套排查链路，再聊几句我这些年积累下来的原则，面试和实战都通用。
第一，每次都从"现象量化"开始，而不是从猜原因开始。用户说"卡"，你要问的是"多卡？全卡还是部分？从什么时候开始？"这些信息决定了后面命令的使用方向。数据永远比感觉可靠。
第二，给每个环境准备一个"命令速查本"。我以前排查问题靠记忆，后来发现压力状态下记性会变差，就养成了写速查笔记的习惯。把常用的排查套路、每个命令的关键指标、正常阈值范围都记下来，出问题时翻笔记比翻脑子快得多。这个速查本现在已经成了团队新人的入门读物。
第三，面试的本质是复述你的思考过程，不是背答案。同样的8个命令，你如果只是说"我会用top看CPU、free看内存"，那是简历上的字。如果你说"我先确认负载和CPU比值，再看us/sy分辨是用户态还是内核态，然后顺着进程找锁竞争和上下文切换"，面试官听到的是一个有完整方法论的人。按这个思路准备，面试基本就稳了。
