6. 性能瓶颈定位思路

性能瓶颈定位是性能测试面试中最能拉开差距的问题。会跑 JMeter 的人很多，但能根据响应时间、TPS、错误率、CPU、内存、数据库、线程池、连接池、GC、日志等信息定位瓶颈的人不多。面试官问瓶颈定位，真正想听的是你的分析路径，而不是随便说“可能是数据库问题”。

性能瓶颈定位要遵循一个原则：先看现象，再看资源，再看链路，最后验证猜想。不要一上来就下结论。

一、先描述现象

性能问题常见现象：

响应时间升高；
TPS 上不去；
TPS 下降；
错误率上升；
超时增多；
CPU 打满；
内存持续上涨；
数据库慢 SQL；
连接池耗尽；
MQ 积压。

不同现象对应不同排查方向。

二、看压测结果趋势

先看三条曲线：

响应时间；
TPS；
错误率。

如果并发增加后，TPS 不再增长、响应时间继续升高，说明系统达到瓶颈。

如果错误率上升，要看是 HTTP 错误、超时、业务错误还是断言失败。

三、看应用服务器资源

应用服务器关注：

CPU 使用率；
Load；
内存；
GC；
线程数；
线程池队列；
连接池；
日志错误。

CPU 高可能是计算密集、锁竞争、频繁 GC 或代码循环问题。

CPU 不高但响应慢，可能是等待数据库、网络、外部服务或锁。

四、看数据库

数据库是常见瓶颈。

关注：

慢 SQL；
SQL 执行计划；
索引是否命中；
连接数；
锁等待；
行锁表锁；
CPU 和 IO；
buffer pool；
主从延迟。

如果应用 CPU 不高，但数据库 CPU 或慢 SQL 很高，重点排查数据库。

五、看缓存 Redis

Redis 瓶颈可能表现为：

响应时间升高；
热 key；
大 key；
连接数过高；
命中率低；
缓存穿透；
网络 IO 高。

如果大量请求打到数据库，可能是缓存失效或命中率低。

六、看 MQ

异步链路要看 MQ。

关注：

消息积压；
消费速度；
消费失败；
重试次数；
死信队列；
消费者线程数。

接口返回快，但最终状态延迟，可能是 MQ 消费瓶颈。

七、看网络和网关

网络或网关问题可能导致：

连接超时；
502/503/504；
响应波动；
带宽打满；
Nginx 连接数限制；
网关限流。

要区分服务自身慢和网关层慢。

八、看压测机自身

有时瓶颈不在被测系统，而在压测机。

检查压测机：

CPU；
内存；
网络带宽；
JMeter 堆内存；
线程数；
是否开启大量监听器。

如果压测机资源打满，测试结果不可信。

九、定位路径示例

现象：并发增加到 500 后，TPS 不再上涨，响应时间从 300ms 升到 3s，错误率增加。

排查：

看应用 CPU，发现不高；
看应用日志，有数据库连接等待；
看数据库连接池，连接数打满；
看慢 SQL，有订单查询未走索引；
优化索引后复测，响应时间下降，TPS 上升。

这就是完整定位闭环。

十、常见错误

只看 JMeter 报告；
一上来就说数据库慢；
不看压测机资源；
不区分 HTTP 错误和业务错误；
不看日志；
没有复测验证；
没有保留监控截图和数据。

十一、面试回答模板

如果面试官问“性能瓶颈定位思路”，可以这样回答：

我定位性能瓶颈会先看压测结果趋势，包括响应时间、TPS 和错误率，判断是在什么压力点出现拐点。然后看应用服务器资源，比如 CPU、内存、Load、GC、线程池和连接池。如果应用 CPU 高，可能是代码计算、锁竞争或 GC；如果 CPU 不高但响应慢，可能是在等数据库、缓存、MQ 或外部服务。接着看数据库慢 SQL、连接数、锁等待和索引命中，再看 Redis 热 key、大 key、命中率，MQ 是否积压，网关是否限流。同时也要检查压测机自身资源，避免压测机成为瓶颈。定位后要做优化并复测，形成闭环。

十二、练习清单

分析响应时间升高；
分析 TPS 上不去；
分析错误率升高；
看应用 CPU；
看数据库慢 SQL；
看连接池；
看 GC；
看 Redis 命中率；
看 MQ 积压；
写瓶颈定位案例。

性能瓶颈定位不是猜，而是基于现象、指标、日志和复测形成证据链。

配套刷题：

性能测试面试题