运维排查篇 | Redis占用内存过高怎么办

我们知道，Redis是一个key-value数据库，它的数据是运行在内存中的

其读写效率比将数据存储到磁盘上的数据库要快很多

虽然性能强大，但是如果我们不了解Redis的内存回收策略，就有可能导致Redis消耗内存过高甚至导致内存溢出，严重影响系统性能

案例现象

发现生产环境上的一台服务器出现内存使用率达到阈值的告警

登上服务器使用 top 命令先看下系统资源整体使用的情况

top

通过 top 的输出发现：

• 系统平均负载没有异常

• 系统cpu使用率没有异常

• 系统已使用的物理内存（used）数值特别高，达到了总物理内存的80%以上

• 而且buffer/cache的数值也不小，这说明有应用产生了大量的读写缓存

光看系统资源整体使用情况不能精确的定位到问题

我们继续观察 top 输出，这次我们将重点放到了各个进程的资源使用情况

发现：

• redis进程占用了最多的内存，达到了20G

• redis进程的使用率也达到了90%以上

由 top 的输出我们不难发现，这台服务器上的 redis实例消耗了大量的内存，而且cpu使用率很高，应该是有应用往 redis 上进行大量的读写操作

定位问题

这台服务器上的 Redis 是运行在 docker 上的，我们进入到 redis 容器里面

docker exec -it redis /bin/bash 

我们还可以使用如下命令来查看 redis 容器的一些详细信息

docker inspect redis

然后找到 Redis 的配置文件路径，检查一下是不是配置出了问题

与对部署相同服务的服务器redis配置文件对比了一下，发现配置并没有什么问题

不是配置问题，那到底是什么原因导致Redis占用了这么多内存？这些使用的内存Redis不会回收的吗？

在回答这些问题时，我们先来了解一下Redis的内存回收策略以及键过期机制

内存回收策略

Redis是基于内存的数据库，常被用作缓存，以此来提高系统的响应速率与性能

Redis内存消耗

Redis进程的内存消耗主要包括：自身内存 + 对象内存 + 缓冲内存 + 内存碎片

自身内存

一般来讲，Redis空进程自身内存消耗非常少，通常 usedmemoryrss 在 3MB 左右时，used_memory 一般在 800KB 左右

一个空的 Redis 进程消耗内存可以忽略不计

对象内存

对象内存是Redis内存占用最大的一部分，因为它存储着用户所有的数据

对象内存消耗可以简单理解为这两个对象（Key和Value）的内存消耗之和(还有类似过期之类的信息)

使用 Redis 时很容易忽略键对内存消耗的影响，应当避免使用过长的键以及给键设置一个过期时间

缓冲内存

缓冲内存主要包括客户端缓冲、复制积压缓冲和AOF缓冲

客户端缓冲指的是所有接入到 Redis 服务器 TCP 连接的输入输出缓冲

复制积压缓冲区是Redis 在 2.8 版本后提供的一个可重用的固定大小缓冲区，用于实现部分复制功能，根据 repl-backlog-size 参数控制，默认 1MB。对于复制积压缓冲区整个主节点只有一个，所有的从节点共享此缓冲区。因此可以设置较大的缓冲区空间，比如说 100MB，可以有效避免全量复制

AOF 重写缓冲区这部分空间用在AOF 重写期间保存最近的写入命令。AOF 重写缓冲区的大小用户是无法控制的，取决于 AOF 重写时间和写入命令量，不过一般都很小

内存碎片

Redis内部有自己的内存管理器，为了提高内存使用的效率，实现对内存的申请和释放进行管理。

Redis中的值删除的时候，并没有把内存直接释放交还给操作系统，而是交给了Redis内部有内存管理器。这就使得如果大量的key在短时间内过期被删除，这些内存不会释放给操作系统，而是交给内部内存管理器， 从而导致redis实际占用的内存与申请的内存相差过大，就会导致大量的内存碎片

Redis 正常碎片率一般在 1.03 左右

PS：子进程内存消耗

除此之外，Redis实例的内存消耗还有一部分是子进程的内存消耗，子进程内存消耗主要指执行 AOF 重写 或者进行 RDB 保存时 Redis 创建的子进程内存消耗

Redis 内存相关的指标

我们可以通过info memory 命令可以获得 Redis 内存相关的指标

127.0.0.1:6379 > info memory

这里我们挑三个比较重要的字段来讲一下

• mem_fragmentation_ratio

当该值 > 1时，说明有部分内存并没有用于数据存储，而是被内存碎片所消耗，如果该值很大，说明碎 片率严重

当该值 < 1时，一般是因为操作系统把 Redis 内存中的数据 swap 到硬盘里面，出现这种情况要格外关注，因为硬盘速度远远慢于内存，所以 Redis 性能会变得很差，甚至僵死

建议设置和内存一样大小的交换区，如果没有交换区，一旦 Redis 突然需要的内存大于当前操作系统可用内存时，Redis 会因为内存溢出而被内核的 OOM 机制直接杀死

• maxmemory

Redis 使用 maxmemory 参数限制最大可用内存。限制内存的目的主要有：

1、用于缓存场景，当超出内存上限 maxmemory 时使用 LRU 等回收策略释放空间

2、防止所用的内存超过服务器物理内存，导致 OOM 后进程被系统杀死

maxmemory 限制的是 Redis 实际使用的内存量，也就是 used_memory 对应的内存。

实际消耗的内存可能会比 maxmemory 设置的大，要小心因为这部分内存导致 OOM。所以，如果你有 10GB 的物理内存，最好将 maxmemory 设置为 8 或者9G

• maxmemory_policy

Redis默认采用noeviction策略

volatile-lru：# 在设置了过期时间的所有键中，选取最近最少使用的数据删除volatile-lfu：# 在设置了过期时间的所有键中，选取最近最不常用，也就是一定时期内被访问次数最少的数据删除volatile-random：# 筛选出设置了过期时间的键值对，随机删除。volatile-ttl：# 筛选出设置了过期时间的键值对，越早过期的越先被删除。allkeys-lru：# 在所有键中，选取最近最少使用的数据删除allkeys-lfu：# 在所有键中，选取最近最不常用，也就是一定时期内被访问次数最少的数据删除allkeys-random：# 采用随机淘汰策略删除所有的键值对，这个策略不常用。noeviction：# 不淘汰任何键值对，当内存满时，如果进行读操作，例如get命令，它将正常工作，# 如果做写操作，它将返回错误，# 也就是说，当Redis采用这个策略内存达到最大的时候，它就只能读不能写了

键过期机制

除了上面提到的内存回收机制可以有效解决 Redis 内存使用过高的问题之外，Redis还有一个键过期机制——给key设置一个过期时间，一旦超过过期时间，这个key就会被被删除，内存将被回收

PS：前面一章说的是是内存不足的「回收策略」，这一种是过期键的删除策略，两者是不同的，不要搞混了

我们来看一下相关的命令

• 查看key的过期时间

如果key存在过期时间，返回剩余生存时间(秒)；如果key是永久的，返回-1；如果key不存在或者已过期， 返回-2

TTL单位是秒，PTTL单位是毫秒

127.0.0.1:6379> TTL KEY127.0.0.1:6379> PTTL KEY

• 设置key的过期时间

设置一个key在当前时间"seconds"(秒)之后过期。返回1代表设置成功，返回0代表key不存在或者无法设 置过期时间

EXPIRE单位是秒，PEXPIRE单位是毫秒

语法：EXPIRE key seconds127.0.0.1:6379> EXPIRE name 60(integer) 1

设置一个key在"timestamp"(时间戳(秒))之后过期。返回1代表设置成功，返回0代表key不存在或者无法 设置过期时间

EXPIREAT单位是秒，PEXPIREAT单位是毫秒

语法：EXPIREAT key "timestamp"127.0.0.1:6379> EXPIREAT name 1586941008(integer) 1

SETEX在逻辑上等价于SET和EXPIRE合并的操作，区别之处在于SETEX是一条命令，而命令的执行是原子性 的，所以不会出现并发问题

语法：SETEX key "seconds" "value"127.0.0.1:6379> SETEX name 100 jackOK

给key设置了过期时间，如果 key 过期了 Redis 该怎么处理呢？

Redis 过期 Key 处理

Redis key过期处理的方式有三种：

1、惰性删除

不管键有没有过期都不主动删除，等到每次去获取键时再判断是否过期，如果过期就删除该键，否 则返回键对应的值。这种策略对内存不够友好，可能会浪费很多内存

缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄 露（无用的数据占用了大量的内存）

2、定时删除

在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对 key进行删除

缺点：定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器 产生），性能影响严重，因为每个定时器都会占用一定的 CPU 资源

3、定期删除

系统每隔一段时间就定期扫描一次，发现过期的键就进行删除

可以配置redis.conf 的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率 越快，最Redis性能损耗也越大）

我们在 Redis 当中，其选择的是惰性删除和定期删除的综合使用。

不过 Redis 的定期删除只会扫描设置了过期时间的键，因为设置了过期时间的键 Redis 会单独存储，所以不会出现扫描所有键的情况

如果给键设置了较大的过期时间且没有使用内存回收策略，原本的数据没过期不会被回收，又不断写入新的数据，这样会导致 Redis 消耗的内存不断增大

解决问题

了解了 Redis 的内存回收策略以及键过期机制之后我们分别来看一下

我们首先看一下任意key的过期时间是多少

#从当前数据库中随机返回一个 key127.0.0.1:6379> RANDOMKEY127.0.0.1:6379> TTL key(integer) 12032145

我们发现，key的过期时间设置成了一千多万秒！这个过期时间也太长了吧

再查看一下 Redis 的内存回收策略配置

127.0.0.1:6379> info memorymaxmemory：0maxmemory_policy："noeviction"

可以看到，我们并没有设置内存最大限制，而且内存回收策略是noeviction，即不淘汰任何键值对

查看了这两个选项之后，问题就清晰起来了：

key的过期时间设置的太长，没有设置最大可用内存限制而且内存回收策略是noeviction 就会使得原先的数据还没过期，又有新的数据写进来，导致消耗内存越来越多，而系统又无法进行回收

解决方法

1、重新给键设置过期时间

这个不太现实，因为生产环境中的 Redis 有大量的 Key（十万级甚至百万级），不可能说一个一个的重新设置过期时间

而且我们的 Redis是运行在docker上的，已经打包成一个容器，如果修改的话需要花费大量的时间和精力

2、修改配置文件（推荐使用）

我们可以更改 Redis 的配置，设置最大内存使用限制以及内存回收策略

修改 Redis 配置文件，添加如下两个字段：

maxmemory：10Gmaxmemory_policy："volatile-lru"

我们设置了最大内存使用限制为10G，一旦redis占用内存超过10GB，就会触发内存回收机制volatilelru——在设置了过期时间的key里，删除最近最少使用的key

更改配置后重启一下，等待一段时间后发现 Redis 消耗的内存降下去了，也不再告警了