性能测试必备:Linux性能监控命令,大厂面试最爱考这些!

你好，我是小牛。

最近给同学面试复盘，说自己性能测试面了好几家，一到Linux监控这块就答得稀烂，要么说不出来，要么答得很浅，面试官当场就表情微妙了……

说实话，这个问题我太理解了。

我刚开始做性能测试那会儿，也就会个top命令，知道CPU多少、内存多少，后来在京东做大促性能测试负责人，真正参与过生产全链路压测之后才发现，Linux监控这块水深得很，不是背几个命令就能糊弄过去的。

今天这篇文章，就专门把面试官最爱考的Linux监控命令整理出来，帮你彻底搞定这个高频考点。

一、为什么Linux监控命令是性能测试面试的必考项？

先说一个现象。

我这两年帮不少同学改简历，简历上写熟悉性能测试的人一大把，但一面试，面试官随手一问：压测过程中服务器CPU飙高了，你用什么命令定位？

很多人就卡住了，要么说用top看一下，然后就没了。要么绕开不正面回答，开始聊JMeter报告怎么看……

面试官心里基本上已经有数了。

为什么这块这么重要？道理很简单：压测工具负责施压，Linux监控负责发现问题。你只会压，不会看，那压测做了跟没做有什么区别？

真正的性能测试闭环是：压测施压、实时监控、发现异常、定位瓶颈、协助优化、验证效果。

Linux监控命令，是其中发现异常和定位瓶颈这两个环节的核心武器。

下面我把最高频的几个命令，一个个跟你说清楚。

二、CPU监控：top和vmstat

先说top，这是用得最多的命令，基本上每个测试都知道。

但大部分人只知道用top看CPU使用率，面试官问到深一点就不行了。比如问你：top里面us和sy分别代表什么，有什么区别？

us是用户态CPU占用，就是你的应用程序在消耗CPU。sy是内核态CPU占用，是操作系统在消耗。

一般情况下压测时us高是正常的，说明你的应用在被充分使用。如果sy很高，就要警惕了，可能是系统调用太频繁，比如频繁的文件IO、网络IO，这时候要往IO方向排查。

还有一个指标叫wa，就是IO等待。如果wa持续偏高，说明磁盘IO是瓶颈，CPU在等磁盘，这种情况应用层面再怎么优化也没用，得从存储层下手。

top的用法面试官还喜欢结合一个场景来问：压测时发现某个Java进程CPU 100%，你怎么定位到底是哪段代码的问题？

这道题很经典，答案是一套固定流程：先用top找到CPU最高的进程PID，再用top -Hp加上这个PID找到该进程里CPU最高的线程TID，然后把TID转成十六进制，最后用jstack命令dump出线程堆栈，在堆栈里找到这个十六进制TID对应的线程，看它在执行什么代码。

能把这个流程说清楚，面试官基本上会给你加分。

再说vmstat，这个命令比top更全面，但很多人不太会用。

vmstat可以看CPU的上下文切换次数，就是cs这个字段。如果压测过程中cs非常高，说明线程切换频繁，可能是线程数设置太多了，线程之间互相抢占CPU，反而降低了效率。这种情况下不是继续加压就能提升TPS的，要从线程池配置入手优化。

vmstat还能看到内存的swap情况。如果si和so这两个字段不为零，说明系统在使用swap分区，内存已经不够用了，这时候TPS上不去、响应时间波动大都是正常现象，根本原因是内存瓶颈。

三、内存监控：free和jstat

free命令比较简单，主要看可用内存和swap使用情况，面试一般不会深问。

但是Java应用的内存问题，光看系统层面的free是不够的，还要看JVM内存，这就要用jstat了。

jstat可以实时监控JVM的GC情况，比如看GC频率、GC耗时、各内存区域的使用情况。

面试官很喜欢问这样一道题：压测过程中发现接口响应时间周期性波动，每隔一段时间就会突然变高一次，可能是什么原因？

答案大概率是Full GC。JVM在做Full GC的时候，应用线程会暂停，也就是常说的Stop The World，暂停时间越长，响应时间的波动就越明显。

用jstat可以直接观察到GC的频率和耗时，如果发现Full GC特别频繁，就需要去分析JVM堆内存配置是否合理，或者是否存在内存泄漏。

内存泄漏的问题更复杂一点。特征是压测过程中内存持续上涨，压测停止之后也不回落，GC也回收不了。这种情况要用jmap命令dump出堆内存快照，再配合MAT工具进行分析，找到是哪些对象在持续增长、谁持有了它们的引用。

四、磁盘IO监控：iostat

这个命令很多做功能测试的同学根本没接触过，但在性能测试场景下，磁盘IO往往是一个被忽视的瓶颈点。

iostat主要看几个指标：

%util是磁盘繁忙程度，如果长时间超过80%，说明磁盘IO已经是瓶颈了。

await是IO请求的平均等待时间，如果这个值很高，说明磁盘响应很慢。

r/s和w/s是每秒读写次数，结合业务特点来判断是否合理。

什么时候磁盘IO会成为性能瓶颈？常见的几种情况：数据库日志写入太频繁、应用日志级别设置过低打了太多日志、内存不够导致频繁swap。

面试官如果问到TPS上不去，你从哪几个维度排查，磁盘IO是必须要提到的一个维度，很多同学漏掉这块。

五、网络监控：netstat和sar

netstat主要用来看网络连接状态，压测场景下最常用的是查看TIME_WAIT数量。

如果发现TIME_WAIT非常多，可能是短连接太多导致的，连接建立了用完就关掉，系统来不及回收，TIME_WAIT就会堆积，最终导致端口被耗尽，新的连接建立不了，TPS就上不去了。

这道题面试官也很喜欢考：压测时TPS突然下不去了，错误率开始上升，但CPU和内存都正常，你怎么排查？

如果看到大量TIME_WAIT，基本上就锁定了问题方向——连接池配置不合理或者需要开启端口复用。

sar命令的特点是可以看历史数据，这一点其他命令不具备。压测结束之后，如果要回溯某个时间段系统的资源使用情况，sar是最好用的工具。

比如用sar -u可以看历史CPU，用sar -r可以看历史内存，用sar -n DEV可以看历史网络流量。

在做性能测试报告的时候，这个命令非常实用，可以精确还原压测期间各项指标的变化趋势，而不是靠截图拼凑。

六、面试常见的组合拳题型

上面这些命令单独拿出来，面试官一般不会直接问说说top命令的用法，更多是结合场景来考。

场景一：压测时TPS很低，但错误率也很低，响应时间很长，怎么排查？

思路是先用top看CPU和内存，如果CPU不高，看vmstat看是否有大量等待，再用iostat看磁盘，再用netstat看连接状态。如果系统层面都正常，就往应用层看，用jstack看线程是否有大量WAITING或者BLOCKED的状态，可能是锁的问题，也可能是等待外部资源比如数据库或者第三方接口。

场景二：系统运行一段时间后开始OOM重启，怎么排查？

先用jstat持续监控GC，观察内存增长趋势，确认是不是内存泄漏。触发OOM时用jmap dump堆快照，用MAT分析大对象和引用链，找到泄漏的根源。

场景三：接口响应时间正常，但CPU使用率很高，怎么定位热点代码？

用top -Hp找到热点线程，转成十六进制，jstack dump线程堆栈，定位到具体的方法。如果要更精细，可以用Arthas的profiler命令生成火焰图，直接看到CPU热点方法的分布。

这三类题型基本上覆盖了面试中Linux监控考点的80%，能把这些讲清楚，这块基本稳了。

最后说一个很多同学在面试时容易犯的错误。

面试官问Linux监控命令，不少人开始背命令参数，说了一堆，但说不清楚为什么要这么用，在什么场景下用，看到什么结果意味着什么问题。

这就是典型的只学了工具皮毛，没有真正在项目里实践过。

如果你正在备战性能测试面试，建议把上面几个场景题自己对着说一遍，能流畅说下来才算真的掌握了。

-------------------------------