瓶颈定位怎么做
性能瓶颈定位遵循自顶向下排除法：先确认压测机（施压端）不是瓶颈，再看被测服务自身（CPU、内存、GC、线程池与队列），然后检查依赖（数据库、缓存、下游服务），最后回到链路层（网络、代理、DNS）。每一层都要用指标或采样证据下结论，避免「感觉是数据库慢」式的猜测。
基本信息
| 适用场景 | 压测调优、线上性能劣化定位 |
|---|---|
| 核心原则 | 分层排查、单变量对照、结论附证据 |
| 常用手段 | 系统指标、火焰图与采样分析、慢查询日志、链路追踪 |
| 记录要求 | 各层数据对齐同一时间轴，先后关系可判断 |
典型使用场景
- 压测前先看压测机 CPU、带宽与文件描述符，排除施压端瓶颈
- 服务端 CPU 高：用火焰图找热点函数与锁竞争
- 响应变慢伴随队列增长：核对线程池与连接池配置
- 数据库：慢查询、锁等待、连接数上限逐项核对
- 下游依赖：对照第三方延迟与重试次数，识别级联放大
- 链路层：DNS、代理与网络重传指标单独观察
分层取证示例
分层取证示例
# Linux 压测环境，按同一时间线分层取证
top -H -p <pid> # 线程级 CPU：找热点线程
vmstat 1 10 # 运行队列 r、阻塞进程 b、上下文切换
ss -s # 连接汇总：TIME_WAIT 堆积常是连接复用不足
# MySQL 侧
SHOW FULL PROCESSLIST; # 卡住的查询与锁等待
# 链路侧：对照压测开始时间，查看下游响应时间与错误率曲线分层优先排查
| 层次 | 优先问题 | 典型信号 |
|---|---|---|
| 压测机 | CPU、带宽、fd 是否打满 | 施压工具自身 CPU 满载 |
| 服务端 | CPU 热点、GC 暂停、线程池队列 | 队列长度持续增长 |
| 依赖 | 慢查询、锁等待、缓存命中率 | 数据库响应时间与吞吐背离 |
| 下游 | 第三方延迟、重试与熔断 | 重试次数放大延迟 |
| 链路 | DNS、代理、网络重传 | 首字节时间与连接耗时异常 |
单变量原则：一次只改一个变量并复测，否则无法归因；对照实验的负载曲线与数据规模也要保持一致。
先建基线再优化：优化前后使用同一曲线、同一数据量，结论才可比较；平均值之外同步看分位与最大值。