性能指标不达标:排查思路 + 依据数据 + 定位优化位置 完整流程
先看压测报告:区分是 RT、TPS、错误率还是资源问题;再看服务器资源:CPU / 内存 / IO / 网络,排除底层瓶颈;再看链路监控 + 日志:定位耗时在「代码、数据库、缓存、第三方、中间件」哪一环;最后针对性优化:SQL 索引、代码逻辑、池化参数、异步架构、资源配置。
·
性能指标不达标:排查思路 + 依据数据 + 定位优化位置 完整流程
核心逻辑:先看宏观指标定范围 → 再看分层监控抓瓶颈 → 结合链路日志定位代码 / 架构 / 资源 → 针对性优化
一、先明确:常见不达标指标 & 对应的问题方向
表格
| 不达标指标 | 直观现象 | 大概率瓶颈方向 |
|---|---|---|
| 平均响应时间 / 95/99 时延过高 | 接口慢、页面卡顿 | 代码逻辑、SQL 慢查询、第三方调用、锁竞争 |
| TPS/QPS 上不去、并发压不动 | 并发一高就卡死、吞吐量低 | 应用线程池、连接池、CPU 瓶颈、架构限流、同步阻塞 |
| 错误率飙升(5xx/4xx / 超时) | 压测大量报错 | 服务熔断、连接耗尽、内存溢出、接口限流、依赖服务挂掉 |
| 服务器资源占用异常 | CPU100%、内存暴涨、磁盘 IO 爆满、网卡打满 | 资源瓶颈、内存泄漏、频繁 GC、日志狂打、大数据查询 |
| 抖动严重(响应忽快忽慢) | 性能不稳定 | 垃圾回收、定时任务、锁争抢、数据库冷热数据混杂 |
二、依据什么数据做排查?(必看四层数据)
1. 压测工具层数据(入口第一层)
工具:JMeter、LoadRunner、Gatling、压测平台关键数据:
- 聚合报告:平均 RT、95RT、TPS、错误率、并发数
- 响应时间分布、每秒事务数、请求耗时拆分(连接时间、等待时间、接收时间)
- 超时占比、失败请求堆栈 / 返回报文作用:判断是所有接口都慢,还是个别接口单点慢,缩小排查范围。
2. 应用服务层监控(核心层)
工具:SkyWalking、Pinpoint、Zipkin、Prometheus+Grafana、Arthas关键数据:
- JVM:堆内存、非堆、FullGC/YoungGC 频率 & 耗时、GC 停顿时间、元空间
- 线程:线程总数、阻塞线程、死锁、线程池队列积压、繁忙线程
- 接口链路:各阶段耗时占比(自身代码 / DB/Redis/ 第三方)
- 异常日志:报错堆栈、超时日志、拒绝连接、熔断降级日志
3. 中间件 & 依赖层数据
数据库(MySQL/Oracle):慢 SQL 日志、执行计划、连接数、锁等待、行锁 / 表锁、事务长耗时、索引命中率缓存(Redis):命中率、key 过期淘汰、大 key、热 key、网络耗时、连接数、CPU消息队列(RocketMQ/Kafka):堆积条数、消费速率、分区积压、生产者阻塞网关 / 注册中心:限流阈值、路由转发耗时、连接数
4. 服务器系统层数据(底层)
工具:top、free、df、iostat、netstat、sar关键数据:
- CPU:使用率、上下文切换、负载、CPU 等待 IO
- 内存:剩余内存、swap 占用、缓存占用
- 磁盘:IOPS、读写等待 %、磁盘使用率
- 网络:带宽吞吐、丢包、重传、TCP 连接数(TIME_WAIT/ESTABLISHED)
三、一步步定位瓶颈位置(标准排查顺序)
步骤 1:区分「全局瓶颈」还是「单个接口瓶颈」
- 所有接口 TPS 低、RT 都高 → 服务器 / 基础架构 / 中间件全局问题
- 只有某一个 / 某几个接口不达标 → 业务代码、单条 SQL、特定依赖问题
步骤 2:看系统资源,先排除硬件 / 系统瓶颈
- CPU 持续 90%+定位位置:应用代码死循环、复杂计算、频繁序列化、正则回溯、FullGC、锁自旋
- 内存持续上涨、OOM、频繁 GC定位位置:内存泄漏、大对象未释放、集合滥用、缓存无过期、一次性加载全量数据
- 磁盘 IO 爆满定位位置:未控制日志打印、大批量写入、无索引全表刷盘、文件频繁读写
- 网络带宽 / 连接数打满定位位置:大报文传输、批量接口无分页、第三方接口慢且未限流、短连接过多
步骤 3:无系统资源瓶颈 → 查应用内部(链路追踪)
通过链路耗时拆分,看耗时大头在哪一段:
- 自身业务代码耗时最高优化位置:循环嵌套、重复计算、参数校验冗余、同步串行流程、无效逻辑
- 数据库耗时最高(占比 70% 以上)优化位置:慢 SQL、缺失索引、索引失效、全表扫描、事务过长、多表联查无限制
- Redis / 缓存耗时高优化位置:无缓存、缓存击穿 / 穿透 / 雪崩、大 key 查询、多次重复查缓存
- 第三方 / 下游接口耗时高优化位置:串行调用、未加超时、无熔断、下游性能差未做降级
步骤 4:资源正常、代码 / DB 正常 → 查并发与池化问题
常见问题:
- 数据库连接池、Redis 连接池、线程池核心数过小、队列满、拒绝策略触发
- 接口同步阻塞,没有异步 / 线程池隔离
- 全局锁、悲观锁争抢导致串行化执行优化位置:各类连接池参数、线程池配置、锁优化、异步改造
四、不同瓶颈对应的落地优化方案
1. 响应时间过长优化
- SQL:加合适索引、避免 select *、分页、减少联表、优化执行计划、分库分表
- 代码:循环外查库、本地缓存、批量操作代替循环单次、减少对象创建
- 调用:第三方接口加超时、异步调用、并行请求、结果缓存
2. TPS / 并发上不去优化
- 调优:合理调整线程池、连接池大小,根据 CPU 核心数配置
- 架构:同步改异步、业务解耦、MQ 削峰、读写分离
- 限制:去掉无用限流、调整网关 QPS 阈值、关闭非必要日志打印
3. 内存 & GC 问题优化
- 修复内存泄漏、合理设置 JVM 堆大小、优化 GC 回收策略
- 限制一次性加载数据量、拆分大对象、缓存设置过期时间
4. 频繁报错 / 超时优化
- 增加熔断、降级、重试机制
- 修复连接泄漏、关闭未释放连接
- 排查下游服务稳定性,增加服务隔离
五、极简总结(面试 / 工作直接用)
- 先看压测报告:区分是 RT、TPS、错误率还是资源问题;
- 再看服务器资源:CPU / 内存 / IO / 网络,排除底层瓶颈;
- 再看链路监控 + 日志:定位耗时在「代码、数据库、缓存、第三方、中间件」哪一环;
- 最后针对性优化:SQL 索引、代码逻辑、池化参数、异步架构、资源配置。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐

所有评论(0)