阿里云ecs 8核 16G 内存 装有redis6 分配了3G内存，和2个tomcat 每个tomcat 4G 服务器反应迟钝，如何确认不是redis的问题

我们经常用redis 但遇到tomcat timeout的时候，如何确认不是redis的问题。
不能因为这个再去搞个redis 压力测试。有没有更省劲的方法来确认不是redis的问题

以下是针对 阿里云 ECS（8核16G，Redis 6分配3G内存，2个Tomcat各分配4G）反应迟钝 的 确定性排查流程，所有指标均提供明确的阈值和判断标准：

---

一、系统资源瓶颈排查

1. 内存检查

• 命令：

  free -h        # 查看物理内存和Swap使用
  sar -r 1 5     # 每秒采样内存使用，持续5次
  

• 关键指标：
  • 物理内存剩余：若 available < 1G，系统可能频繁使用 Swap。
  • Swap使用：si（Swap In）和 so（Swap Out）持续 > 0，表明内存不足，直接拖慢性能。

2. CPU检查

• 命令：

  top -H -p <tomcat_pid>  # 查看Tomcat线程CPU占用
  mpstat -P ALL 1         # 查看每个核心的CPU利用率
  

• 关键指标：
  • 总体CPU使用率：若 %us（用户态）或 %sy（系统态）持续 > 70%，表明CPU饱和。
  • 单个核心使用率：若某个核心持续 100%，可能存在单线程热点。

3. 磁盘 I/O 检查

• 命令：

  iostat -x 1  # 查看设备级I/O指标（需安装sysstat）
  

• 关键指标：
  • %util（磁盘利用率）：
    • < 60%：正常。
    • 60%~80%：潜在瓶颈。
    • > 80%：磁盘过载，I/O队列堆积。
  • await（I/O平均等待时间）：
    • < 10ms：正常（SSD）。
    • > 20ms：异常（机械盘 > 5ms 即需警惕）。
  • svctm（服务时间）：
    • SSD应 < 2ms，机械盘 < 10ms。若 await ≫ svctm，表明队列堆积。

4. 网络检查

• 命令：

  sar -n DEV 1    # 查看网卡吞吐量
  ss -s           # 统计TCP连接状态
  

• 关键指标：
  • 带宽占用：若 rxkB/s 或 txkB/s 接近网卡上限（如千兆网卡≈125MB/s），表明带宽饱和。
  • TCP重传：netstat -s | grep retransmit 若重传率 > 0.1%（如总重传数/总包数），网络不稳定。

---

二、Redis 确定性排查

1. 内存压力

• 命令：

  redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio|evicted_keys"
  

• 关键指标：
  • 内存使用：若 used_memory ≥ 2.8G（接近3G），会触发淘汰策略，evicted_keys > 0 表示频繁淘汰数据。
  • 内存碎片率：mem_fragmentation_ratio > 1.5 或 < 0.9 需重启清理。

2. 延迟检测

• 命令：

  redis-cli --latency -h <host> -p <port>  # 持续测试延迟
  

• 正常范围：
  • 本地延迟：99% 请求应 < 1ms（若 > 5ms，Redis可能阻塞）。
  • 网络延迟：跨机房或公网访问时，延迟应 < 10ms。

3. 慢查询与阻塞

• 命令：

  redis-cli slowlog get 10      # 查看最近10条慢查询
  redis-cli info commandstats   # 统计命令耗时
  

• 阈值：
  • 慢查询阈值：默认 10ms，若记录大量 GET/SET 等简单命令，表明Redis负载过高。
  • 阻塞命令：检查是否有 KEYS、FLUSHALL、HGETALL 大Key操作。

4. 持久化影响

• 命令：

  redis-cli info persistence | grep -E "rdb_last_bgsave_status|aof_last_bgrewrite_status|aof_rewrite_in_progress"
  

• 关键点：
  • 若 aof_rewrite_in_progress:1，表示正在重写AOF，此时会大量消耗磁盘I/O和CPU。
  • 检查 rdb_last_bgsave_status:ok，若为 err，持久化失败可能导致内存泄漏。

---

三、Tomcat 确定性排查

1. JVM 内存与GC

• 命令：

  jstat -gc <tomcat_pid> 1000  # 每秒输出GC状态
  

• 关键指标：
  • 堆内存：老年代（OU）若 > 90%，频繁 Full GC。
  • Full GC 频率：若 > 1次/分钟，或单次 Full GC 时间 > 1秒，严重拖慢应用。
  • GC 总耗时：若 FGCT（Full GC总时间）占应用运行时间 > 5%，需优化。

2. 线程阻塞

• 命令：

  jstack <tomcat_pid> | grep "BLOCKED" -c  # 统计阻塞线程数
  

• 阈值：若阻塞线程数 > 活跃线程数的 10%，存在锁竞争或外部依赖阻塞。

3. 外部依赖检查

• 数据库连接池：
  • 检查 maxActive 是否过小，导致等待连接。
  • 使用 netstat -ant | grep <db_port> | wc -l 统计数据库连接数是否超限。
• 外部 API 调用：
  • 在代码中添加日志，记录调用耗时，若 > 500ms，需优化或熔断。

---

四、快速验证 Redis 是否影响

1. 短时间禁用 Redis

• 操作：

  systemctl stop redis   # 停止Redis
  

• 观察：若 Tomcat 响应速度恢复，问题在 Redis；否则继续排查 Tomcat。

2. 模拟 Redis 空负载

• 操作：

  redis-cli FLUSHALL    # 清空数据（慎用！）
  redis-cli CONFIG SET maxmemory 1GB  # 临时降低内存限制
  

• 观察：若性能改善，原 Redis 使用方式有瓶颈（如大Key、高淘汰率）。

---

五、结论与解决方案

若确认 Redis 无问题（满足以下所有条件）：

1. Redis 内存使用 < 2.5G，无频繁淘汰（evicted_keys=0）。
2. Redis 延迟 < 1ms，无慢查询。
3. 系统资源（CPU < 70%，磁盘 %util < 60%，无 Swap）。

问题大概率在 Tomcat：

• JVM 优化：

  # Tomcat 的 catalina.sh 调整参数
  JAVA_OPTS="-Xms3g -Xmx3g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
  

• 线程池调整：
  • 增大 maxThreads（如 800），减少队列等待。
• 代码优化：
  • 避免同步阻塞，使用异步或缓存（如 Redis）。

若系统资源不足：

• 降级配置：
  • Tomcat 堆内存从 4G 降为 3G，腾出 2G 给系统和 Redis。
  • 升级 ECS 规格至 8核32G。