在线上服务运维中性能问题是常见且紧急的故障场景。本文将系统性地介绍性能问题的排查思路和解决方案。一、遇到接口响应慢、CPU高、负载高如何排查第一步确认现象优先保障业务稳定性先确认故障范围是个别用户、部分节点还是全量服务是接口慢、超时还是 CPU / 内存 / IO 高。优先查看告警、监控大盘确认是否影响业务。如果业务受损严重优先做应急止损限流、扩容、重启故障实例、切换流量。先恢复业务再查根因不沉迷现场调优。第二步分层排查从外到内逐层定位瓶颈业务层查看接口监控QPS、响应时间、错误率区分是所有接口慢还是某几个接口慢查看慢请求日志、慢查询。系统层服务器使用 top / htop 查看 CPU 负载free 查看内存iostat、vmstat 查看磁盘 IOnetstat/ss 查看网络连接、TCP 状态。判断瓶颈CPU 高内存泄漏磁盘 IO 打满网络带宽 / 连接数瓶颈。中间件层如果用到 Redis、Kafka、MySQL检查中间件指标。比如 MySQL 慢 SQL、锁等待Redis 大 key、热 keyKafka 分区不足、副本同步阻塞、消费堆积。应用层抓线程栈、jstack (Java)、perf看应用内部是卡在计算、IO还是等待外部资源。第三步定位根因针对性解决问题常见性能问题以及处理手段CPU 高热点循环、频繁 GC、大量计算逻辑 → 优化代码逻辑调整 JVM 参数扩容。内存占用高、内存泄漏内存持续上涨OOM → 导出内存快照分析修复内存泄漏调整内存参数。IO 瓶颈磁盘读写打满数据库慢查询 → 优化 SQL、增加索引、分库分表更换高性能磁盘。数据库慢慢 SQL、缺少索引、锁冲突 → SQL 优化加索引读写分离。中间件瓶颈Redis 大 key、Kafka 消费堆积 → 拆分大 key增加分区、提升消费能力。资源不足流量上涨硬件资源不够 → 横向扩容增加实例。第四步验证效果回归观察监控处理完成后观察监控指标响应时间、负载、错误率确认性能恢复确认问题是否真正解决避免临时恢复后面反复复现。第五步复盘避免再次发生整理故障根因、现象、处理过程补充监控告警完善预案优化架构、SQL、业务逻辑把问题提前发现不要等故障发生。二、常见内存问题场景场景 1瞬时内存尖峰 OOM常与慢查询强相关特征平时内存正常瞬间内存打满。常见诱因SQL 未加 Limit一次性查询上万/几十万行数据全部加载至 JVM 内存MQ 消息突刺大批量消息同时消费大 HTTP 报文、大文件全部读入内存。证据监控显示内存瞬间冲高GC 日志出现大量 FullGC慢查询日志中Rows_sent数值巨大。场景 2内存泄漏特征内存缓慢逐步上涨每次 GC 回收不完全数小时/数天后 OOM。证据监控显示内存持续走高hprof 堆快照分析发现大量无法释放的对象连接池/集合未正确释放。场景 3JVM 参数配置不合理-Xmx设置过大整机物理内存不足触发系统 OOM killer 杀死进程堆外内存、元空间未设限制持续占用内存。虚拟机注意事项JVM 堆内存不应占满整机内存需为系统、buffer、堆外内存预留空间。场景 4整机机器资源不足机器本身内存较小业务流量上涨导致整机内存耗尽操作系统 OOM-killer 随机杀死 Java 进程。三、修复方案瞬时尖峰无 Limit 大批量 SQL修复业务代码SQL 增加 Limit 分页避免全量数据加载至 JVM 内存MQ 增加限流接口增加熔断机制。内存泄漏开发人员根据 hprof 堆快照定位泄漏点修复代码 bug重新发布版本。JVM 参数不合理调优-Xmx、MaxMetaspaceSize为操作系统预留足够内存避免触发系统 OOM killer。整机资源不足扩容机器集群横向扩展多实例或降低单机业务压力。四、精简版适用场景面试官问简单说下遇到性能问题你怎么排查遇到性能问题我首先确认业务影响必要时先应急恢复业务。之后分层排查先看业务监控指标再看服务器 CPU、内存、IO、网络系统指标接着排查数据库、Redis、Kafka 这类中间件最后定位应用内部瓶颈。找到根因之后做对应优化比如 SQL 优化、资源扩容、修复内存泄漏、解决大 key / 慢查询处理完核对监控确认恢复。最后复盘完善告警和预案防止问题重复出现。五、常见问题解答1. CPU 负载很高但是 CPU 使用率不高是什么原因负载高使用率低大概率是IO 阻塞大量进程在等待磁盘 IO查看 iostat 磁盘指标。2. 接口响应慢但是服务器资源都正常优先查外部依赖数据库慢查询、Redis、Kafka第三方接口调用超时线程池阻塞等待外部返回。总结性能问题排查需要系统性的思维和科学的流程从现象确认到根因定位再到解决验证和复盘优化形成完整的闭环。
