定位生产环境性能问题

问题描述

API 响应时间从平均 50ms 突然上升到 500ms，用户开始投诉。监控显示 CPU 和内存正常，数据库连接数正常。

没有最近的代码发布，问题原因不明。

传统思路

查看监控大盘 - 各项指标看起来正常
检查数据库慢查询 - 没有明显的慢查询
查看最近变更 - 没有代码发布
盲目尝试 - 重启服务、扩容实例
升级给 DBA/运维 - 多团队协作排查

预计耗时：数小时，涉及多人

AI思维

第一步：系统性收集信息

我们的 API 响应时间突然变慢（50ms → 500ms），请帮我制定排查计划。

## 已知信息
- 影响范围：所有 API
- 开始时间：今天下午 2 点
- CPU/内存/数据库连接数正常
- 无最近代码发布

## 系统架构
用户 → Nginx → Spring Boot API → MySQL + Redis

请给我一个系统性的排查清单，从最可能的原因开始。

第二步：AI 提供排查框架

AI 回复：

基于你的描述，这是一个系统性的延迟增加。我建议按以下顺序排查：
第一优先级：外部依赖
Redis 响应时间 - 检查 Redis 是否有延迟
MySQL 响应时间 - 不只看慢查询，看平均响应时间
外部 API 调用 - 如果有调用第三方服务
第二优先级：网络层
服务间网络延迟
DNS 解析时间
负载均衡健康检查
第三优先级：应用层
GC 日志 - 是否有频繁 Full GC
线程池状态 - 是否有线程阻塞
连接池状态 - 虽然连接数正常，但可能有等待
具体排查命令：

bash

# 检查 Redis 延迟
redis-cli --latency-history -i 1

# 检查 MySQL 响应时间
mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"
mysql -e "SHOW PROCESSLIST;"

# 检查 GC 情况
jstat -gcutil <pid> 1000

# 检查线程状态
jstack <pid> | grep -A 20 "BLOCKED"

第三步：定位问题

执行 AI 建议的检查，发现 Redis 延迟异常：

检查结果：
- Redis 延迟从平均 1ms 上升到 100ms
- 其他指标正常

请继续分析 Redis 延迟的可能原因。

AI 继续分析：

Redis 延迟突然上升，常见原因：
大 Key 问题 - 某个 Key 的 value 过大
热点 Key - 某个 Key 被频繁访问
慢命令 - KEYS、HGETALL 等 O(n) 命令
内存不足 - 触发 swap 或淘汰
网络问题 - Redis 服务器网络
持久化 - RDB/AOF 导致阻塞
诊断命令：

bash

# 检查慢日志
redis-cli SLOWLOG GET 10

# 检查大 Key
redis-cli --bigkeys

# 检查内存
redis-cli INFO memory

# 检查是否在做持久化
redis-cli INFO persistence

第四步：找到根因

发现问题：
redis-cli SLOWLOG GET 10 显示大量 KEYS 命令，耗时 200ms+

代码中搜索发现：
```java
// 某个定时任务（下午2点新上线的配置）
@Scheduled(cron = "0 * * * * *")  // 每分钟执行
public void cleanExpiredSessions() {
    Set<String> keys = redisTemplate.keys("session:*");
    // ...
}

这个新配置在下午2点生效，每分钟执行 KEYS 命令。

请给出修复方案。


AI 给出修复方案：

```java
// 修复方案：使用 SCAN 替代 KEYS
public void cleanExpiredSessions() {
    ScanOptions options = ScanOptions.scanOptions()
        .match("session:*")
        .count(100)
        .build();

    try (Cursor<byte[]> cursor = redisTemplate.scan(options)) {
        while (cursor.hasNext()) {
            String key = new String(cursor.next());
            // 处理单个 key
        }
    }
}

// 更好的方案：使用 Redis 自带的过期机制
// 设置 key 时直接设置 TTL，让 Redis 自动清理
redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES);

结果对比

指标	传统方式	AI思维
排查时间	2-4小时	30分钟
涉及人员	开发+DBA+运维	1人
系统性	凭经验，可能遗漏	完整检查清单
修复质量	可能只解决表面	根因+最佳实践

关键洞察

系统性思维：让 AI 帮你列出完整的排查清单，避免遗漏
逐步深入：从现象到原因，一步步缩小范围
实际执行：AI 给方向，人执行并反馈结果
最佳实践：AI 不只给解决方案，还给出为什么这样更好

排查模板

我遇到一个性能问题，请帮我分析。

## 现象
[具体描述：什么变慢了，从多少到多少]

## 时间线
[什么时候开始的，是否有规律]

## 已排除的原因
[你已经检查过什么，结果是什么]

## 系统架构
[简要描述系统组成]

## 最近变更
[代码、配置、基础设施的变更]

请给我一个系统性的排查计划。

定位生产环境性能问题 ​

问题描述 ​

传统思路 ​

AI思维 ​

第一步：系统性收集信息 ​

第二步：AI 提供排查框架 ​

第三步：定位问题 ​

第四步：找到根因 ​

结果对比 ​

关键洞察 ​

排查模板 ​

定位生产环境性能问题

问题描述

传统思路

AI思维

第一步：系统性收集信息

第二步：AI 提供排查框架

第三步：定位问题

第四步：找到根因

结果对比

关键洞察

排查模板