面试讲到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问题出在availablefree太常见了常见到很多人用它只是看一眼数字而已。但内存排查里最大的误区恰恰就藏在这里以为free那一列是剩余内存。现在的系统里free -h输出的free列是完全没有被使用的内存而真正反映可用程度的是available列。因为Linux内核会把空闲内存拿来当缓存buff/cache这些内存在需要时可以回收给应用程序用所以available才是在不触发交换的情况下还能新分配给进程的内存的估算值。你看free只有几百MB但如果buff/cache占了几个Gavailable也还有几个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-depth1 -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 / netstatTIME_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按时间窗口回放应用日志。比如怀疑OOMdmesg -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分辨是用户态还是内核态然后顺着进程找锁竞争和上下文切换面试官听到的是一个有完整方法论的人。按这个思路准备面试基本就稳了。
面试讲到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问题出在availablefree太常见了常见到很多人用它只是看一眼数字而已。但内存排查里最大的误区恰恰就藏在这里以为free那一列是剩余内存。现在的系统里free -h输出的free列是完全没有被使用的内存而真正反映可用程度的是available列。因为Linux内核会把空闲内存拿来当缓存buff/cache这些内存在需要时可以回收给应用程序用所以available才是在不触发交换的情况下还能新分配给进程的内存的估算值。你看free只有几百MB但如果buff/cache占了几个Gavailable也还有几个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-depth1 -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 / netstatTIME_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按时间窗口回放应用日志。比如怀疑OOMdmesg -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分辨是用户态还是内核态然后顺着进程找锁竞争和上下文切换面试官听到的是一个有完整方法论的人。按这个思路准备面试基本就稳了。
