线上问题排查实例分析｜关于 Redis 内存泄漏

Redis 作为高性能的 key-value 内存型数据库，普遍使用在对性能要求较高的系统中，同时也是滴滴内部的内存使用大户。本文从 KV 团队对线上 Redis 内存泄漏定位的时间线维度，简要介绍 Linux 上内存泄漏的问题定位思路和工具。

16:30 问题暴露

业务反馈缩容后内存使用率90%告警，和预期不符合，key 只有1万个，使用大 key 诊断，没有超过512字节以上的大 key。

16:40 确认内存泄漏

发现该系统中有部分实例内存明显偏高达到300~800MB，正常实例只有10MB左右，版本号为4ce35dea，在9月份时已经有发现49bdcd0b这个较老版本有内存泄漏情况发生，现象看起来一样，说明内存泄漏问题一直存在，未被修复，于是开始排查该问题。

17:30 开始排查社区版本

排查问题先易后难，先排除是不是社区的版本Bug问题：

• 不需要从最新修复一直倒叙确认到3系列的 commit 提交，因为如果是严重的内存泄漏，3系列的旧版本也一定会有 backport 修复记录。

查看3.2.8的commit记录，只有一次内存泄漏相关提交：Memory leak in clusterRedirectBlockedClientIfNeeded.

本次提交只修复了在 cluster 出现 key 重定向错误时对 block client 处理时对一个指针的泄漏，不可能出现如此大的泄漏量。3.2.8的社区版已上线数年，但在社区内未搜索到相关内存泄漏问题，因此推测是我们的某些定制功能开发引入的 Bug。

18:10 整理监控和日志

整理当前已知监控和日志信息，分析问题的表面原因和发生时间

1、监控信息

odin 监控只能看到最近两个月的内存使用曲线，从监控上可以得到三点信息：

• 两个月前已经发生内存泄漏

• 内存泄漏不是持续发生的，是由于某次事件触发的

• 内存泄漏量大，主实例使用内存800MB，从实例使用内存10MB