真实命令 · 少走弯路·已沉淀 95 篇排障/命令手册，25 份速查表，15 个配置工具进入排障台
LaoHand开发者排障手册
配置生成

database Troubleshooting

Redis 内存占用过高与淘汰策略排查

Redis 内存持续上涨、报 OOM command not allowed when used memory > 'maxmemory' 或 evicted_keys 飙升时，先用 INFO memory 看 used_memory/maxmemory，CONFIG GET maxmemory-policy 确认策略是否 noeviction，再用 --bigkeys 找大 key 并检查 TTL 是否缺失。

先确认 used_memory、maxmemory 和淘汰策略，再找大 key、过期时间缺失和写入突增。Redis 内存问题通常是数据模型或 TTL 策略问题。

适用环境Linux / 数据库 / 连接池
风险等级低
最后验证2026-06-30
建议权限普通用户

2026-06-30 更新·约 3 分钟阅读

Scenario

这篇文章解决什么问题

适用于“Redis 内存占用过高与淘汰策略排查”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。先确认 used_memory、maxmemory 和淘汰策略，再找大 key、过期时间缺失和写入突增。Redis 内存问题通常是数据模型或 TTL 策略问题。

Symptoms

典型现象

  • Redis 内存持续上涨、报 OOM command not allowed when used memory > 'maxmemory' 或 evicted_keys 飙升时，先用 INFO memory 看 used_memory/maxmemory，CONFIG GET maxmemory-policy 确认策略是否 noeviction，再用 --bigkeys 找大 key 并检查 TTL 是否缺失。
  • 相关日志、命令或页面中反复出现 redis、memory、bigkeys 等关键词。
  • 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。

Before Debugging

排查前先确认

  • 先区分连接、认证、锁、慢查询、连接池、内存或持久化问题。
  • 记录数据库端时间、应用实例数、连接池大小和报错 SQL。
  • 任何 kill/调参前先确认是否影响正在执行的业务事务。

Root Causes

常见根因分层

连接池与数据库容量失配

实例数乘以每个实例连接池上限，可能远超数据库 max_connections；连接泄漏和慢查询会进一步放大问题。

  • 统计来源用户和主机
  • 查看 Sleep 与活跃连接比例
  • 核对应用连接池配置

事务、锁和慢查询堆积

锁等待、长事务、缺索引更新和慢 SQL 会拖住连接，最终表现成连接数耗尽或接口超时。

  • 查 processlist / innodb_trx
  • 看 deadlock 和 lock waits
  • 定位 blocking session

缓存或内存策略失控

Redis 大 key、无 TTL、noeviction、MySQL buffer/临时表配置都可能让系统进入持续抖动。

  • 先看内存水位和策略
  • 找大 key/慢查询
  • 评估数据模型是否合理

Diagnosis Path

分步诊断流程

1. 固定现场，避免追着变化状态跑

先记录故障时间、影响入口、完整错误和最近一次变更。Redis 内存占用过高与淘汰策略排查 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。

  • 截图或保存完整错误文本
  • 记录请求域名/IP/端口/namespace/服务名
  • 标出最近发布、配置、证书、镜像或依赖变更
1. 固定现场，避免追着变化状态跑
redis-cli INFO memory
redis-cli CONFIG GET maxmemory-policy

2. 在故障发生的同一位置复现

很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。

  • 从报错服务所在机器执行测试
  • 必要时加 Host、SNI、namespace 或代理参数
  • 把成功路径和失败路径的输出并排比较
2. 在故障发生的同一位置复现
redis-cli CONFIG GET maxmemory-policy
redis-cli --bigkeys
redis-cli SLOWLOG GET 20

3. 读取服务端证据，而不是只看客户端提示

客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。

  • 确认 Redis 是否设置 maxmemory，以及当前 used_memory_human。
  • 检查 maxmemory-policy 是否符合缓存场景，避免 noeviction 导致写入失败。
  • 用 --bigkeys 或抽样扫描找异常大 key。
3. 读取服务端证据，而不是只看客户端提示
redis-cli --bigkeys
redis-cli SLOWLOG GET 20
redis-cli INFO stats | grep evicted_keys

4. 做最小修复并立即回归验证

每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。

  • 用 --bigkeys 或抽样扫描找异常大 key。
  • 检查关键业务 key 是否缺少 TTL 或 TTL 过长。
  • 根据业务重要性拆分大 key、压缩 value、补 TTL 或扩容。
4. 做最小修复并立即回归验证
redis-cli SLOWLOG GET 20
redis-cli INFO stats | grep evicted_keys

Commands

排查命令与使用意图

命令 1

用于验证 Redis 连接连通性和服务状态。重点看 PONG 响应、连接数和内存使用，排除认证失败和网络隔离。

命令 1
redis-cli INFO memory

命令 2

用于验证 Redis 连接连通性和服务状态。重点看 PONG 响应、连接数和内存使用，排除认证失败和网络隔离。

命令 2
redis-cli CONFIG GET maxmemory-policy

命令 3

用于验证 Redis 连接连通性和服务状态。重点看 PONG 响应、连接数和内存使用，排除认证失败和网络隔离。

命令 3
redis-cli --bigkeys

命令 4

用于验证 Redis 连接连通性和服务状态。重点看 PONG 响应、连接数和内存使用，排除认证失败和网络隔离。

命令 4
redis-cli SLOWLOG GET 20

命令 5

用于验证 Redis 连接连通性和服务状态。重点看 PONG 响应、连接数和内存使用，排除认证失败和网络隔离。

命令 5
redis-cli INFO stats | grep evicted_keys

Risk Notes

容易踩坑的地方

  • 不要只调大 max_connections 掩盖连接泄漏或慢查询，这会让问题在更大规模上爆发。
  • 不要在不了解用途时 FLUSHALL、DROP 或重启数据库，先确认这些操作对各业务的影响。
  • 不要在生产环境直接执行未在测试环境验证过的 DDL 或 DML 操作。

Verification

修复后怎么确认

  • 原始故障现象已经消失，且使用同一入口重新测试 Redis 内存占用过高与淘汰策略 能稳定成功。
  • 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
  • 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。

Prevention

后续预防

  • 为连接数、慢查询、锁等待和内存使用建立趋势监控，在问题发生前发现异常趋势。
  • 把连接池大小按实例总数统一规划，而不是每个服务单独拍脑袋，避免 max_connections 被耗尽。
  • 对批量更新、迁移脚本和缓存写入设置限速与回滚方案，防止误操作导致大范围故障。
  • 定期审查慢查询日志和索引使用情况，主动优化而非被动应对。

常见问题

为什么内存没到机器上限就写入失败？

Redis 受 maxmemory 限制。如果策略是 noeviction，达到限制后写命令会失败。

可以直接 FLUSHALL 吗？

生产环境不要直接执行。应先确认实例用途、备份和影响范围，缓存也可能承载登录态或限流数据。

Long-tail SEO

你可能正在搜索这些报错

下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。

  • Redis 内存占用过高
  • Redis maxmemory-policy noeviction
  • Redis OOM command not allowed
  • redis-cli bigkeys 大 key
  • Redis evicted_keys 增长
  • Redis used_memory_human 过高
  • Redis TTL 缺失 内存上涨
  • Redis maxmemory 淘汰策略

Related

相关排障 / 命令 / 工具

按分类和标签关联的排障流程、命令模板和配置工具，方便顺着同一个问题继续往下查。

排障

Redis 连接不上怎么排查

Redis 客户端报 Could not connect: Connection refused 或 NOAUTH Authentication required 时，先确认 6379 端口是否监听、redis.conf 的 bind 是否限制为 127.0.0.1、protected-mode 是否阻止远程访问，再核对 requirepass 密码和 Docker 端口映射与容器网络。

database速查

MySQL 常用命令速查表

MySQL 日常运维命令一页速查：连接与用户管理、库表操作、查询与索引、进程与锁排查、备份恢复和主从状态检查等 30+ 高频操作，含关键参数说明与典型排障场景示例。

database命令

MySQL 查看锁等待和事务命令

MySQL 排查锁等待和事务阻塞的常用命令，SHOW FULL PROCESSLIST 看当前活跃会话与状态，SHOW ENGINE INNODB STATUS 读 LATEST DETECTED DEADLOCK，information_schema.innodb_trx 和 performance_schema.data_lock_waits 找 blocking 事务，必要时 KILL <thread_id>。

database速查

PostgreSQL 常用命令速查表

PostgreSQL 日常运维命令一页速查：连接与角色管理、库表操作、查询分析、锁与事务排查、备份恢复和复制状态检查等 30+ 高频操作，含关键参数说明与典型排障场景示例。

database排障

MySQL Lock wait timeout exceeded 排查

MySQL 报 Lock wait timeout exceeded; try restarting transaction 时，用 SHOW ENGINE INNODB STATUS 看 LATEST DETECTED DEADLOCK，通过 information_schema.innodb_trx 与 data_lock_waits 找 blocking 事务，短期 kill 会话，长期缩短事务并补索引避免大范围锁。

database排障

MySQL Too many connections 排查与缓解

MySQL 报 Too many connections、连接数达到 max_connections 时，SHOW PROCESSLIST 按用户/IP/数据库/状态聚合连接，识别大量 Sleep 或长时间 Sending data 的会话，检查应用连接池 max pool size 是否超过数据库承载，而不是盲目调大 max_connections。

database