美团在Redis上踩过的一些坑-3.redis内存占用飙升

偏执的太偏执、 2022-08-21 04:22 161阅读 0赞

# 转载请注明出处哈:[http://carlosfu.iteye.com/blog/2254154][http_carlosfu.iteye.com_blog_2254154] #

--------------------

#      #

一、现象：

redis-cluster某个分片内存飙升，明显比其他分片高很多，而且持续增长。并且主从的内存使用量并不一致。

![点击查看原始大小图片][c1763302-3ce3-3aa1-ab06-b79c9a5568f9.jpg]

二、分析可能原因：

1.  redis-cluster的bug （这个应该不存在）

2. 客户端的hash(key)有问题，造成分配不均。（redis使用的是crc16, 不会出现这么不均的情况）

3. 存在个别大的key-value: 例如一个包含了几百万数据set数据结构（这个有可能）

4. 主从复制出现了问题。

5. 其他原因

三、调查原因：

1. 经查询，上述1-4都不存在

2. 观察info信息，有一点引起了怀疑： client\_longes\_output\_list有些异常。

![20306491-4a21-3c80-8f85-422486411458.jpg][]

3. 于是理解想到服务端和客户端交互时，分别为每个客户端设置了输入缓冲区和输出缓冲区，这部分如果很大的话也会占用Redis服务器的内存。

![3c42bdf1-d1e1-3f69-91ff-d202216708bc.png][]

从上面的client\_longest\_output\_list看，应该是输出缓冲区占用内存较大，也就是有大量的数据从Redis服务器向某些客户端输出。

于是使用client list命令（类似于mysql processlist） redis-cli -h host -p port client list | grep -v "omem=0"，来查询输出缓冲区不为0的客户端连接，于是查询到祸首monitor，于是豁然开朗.

![点击查看原始大小图片][0fe3710a-48f9-37bc-b8d5-1512b09547ef.png]

monitor的模型是这样的，它会将所有在Redis服务器执行的命令进行输出，通常来讲Redis服务器的QPS是很高的，也就是如果执行了monitor命令，Redis服务器在Monitor这个客户端的输出缓冲区又会有大量“存货”，也就占用了大量Redis内存。

![95416cca-1bce-39b5-b53e-ff920e9df35c.png][]

四、紧急处理和解决方法

进行主从切换（主从内存使用量不一致），也就是redis-cluster的fail-over操作，继续观察新的Master是否有异常，通过观察未出现异常。

查找到真正的原因后，也就是monitor，关闭掉monitor命令的进程后，内存很快就降下来了。

五、 预防办法：

1. 为什么会有monitor这个命令发生，我想原因有两个：

(1). 工程师想看看究竟有哪些命令在执行，就用了monitor

(2). 工程师对于redis学习的目的，因为进行了redis的托管，工程师只要会用redis就可以了，但是作为技术人员都有学习的好奇心和欲望。

2. 预防方法：

(1) 对工程师培训，讲一讲redis使用过程中的坑和禁忌

(2) 对redis云进行介绍，甚至可以让有兴趣的同学参与进来

(3) 针对client做限制，但是官方也不建议这么做，官方的默认配置中对于输出缓冲区没有限制。

Java代码   ![收藏代码][icon_star.png]

1.  client-output-buffer-limit normal 0 0 0

(4) 密码：redis的密码功能较弱，同时多了一次IO

(5) 修改客户端源代码，禁止掉一些危险的命令(shutdown, flushall, monitor, keys \*)，当然还是可以通过redis-cli来完成

(6) 添加command-rename配置，将一些危险的命令(flushall, monitor, keys \* , flushdb)做rename，如果有需要的话，找到redis的运维人员处理

Java代码   ![收藏代码][icon_star.png]

1.  rename-command FLUSHALL "随机数"  
2.  rename-command FLUSHDB "随机数"  
3.  rename-command KEYS "随机数"

六、模拟实验：

1.  开启一个空的Redis(最简，直接redis-server)

Java代码   ![收藏代码][icon_star.png]

1.  redis-server

初始化内存使用量如下：

Java代码   ![收藏代码][icon_star.png]

1.  \# Memory  
2.  used\_memory:815072  
3.  used\_memory\_human:795.97K  
4.  used\_memory\_rss:7946240  
5.  used\_memory\_peak:815912  
6.  used\_memory\_peak\_human:796.79K  
7.  used\_memory\_lua:36864  
8.  mem\_fragmentation\_ratio:9.75  
9.  mem\_allocator:jemalloc-3.6.0

client缓冲区：

Java代码   ![收藏代码][icon_star.png]

1.  \# Clients  
2.  connected\_clients:1  
3.  client\_longest\_output\_list:0  
4.  client\_biggest\_input\_buf:0  
5.  blocked\_clients:0

2. 开启一个monitor：

Java代码   ![收藏代码][icon_star.png]

1.  redis-cli -h 127.0.0.1 -p 6379 monitor

3. 使用redis-benchmark：

Java代码   ![收藏代码][icon_star.png]

1.  redis-benchmark -h 127.0.0.1 -p 6379 -c 500 -n 200000

4. 观察

(1) info memory：内存一直增加，直到benchmark结束，monitor输出完毕，但是used\_memory\_peak\_human（历史峰值）依然很高--观察附件中日志

(2)info clients: client\_longest\_output\_list： 一直在增加，直到benchmark结束，monitor输出完毕，才变为0 \--观察附件中日志

(3)redis-cli -h host -p port client list | grep "monitor" omem一直很高，直到benchmark结束，monitor输出完毕，才变为0 \--观察附件中日志

监控脚本：

Java代码   ![收藏代码][icon_star.png]

1.  **while** \[ 1 == 1 \]  
2.  **do**  
3.  now=$(date "+%Y-%m-%d\_%H:%M:%S")  
4.  echo "=========================$\{now\}==============================="  
5.  echo " \#Client-Monitor"  
6.  redis-cli -h 127.0.0.1 -p 6379 client list | grep monitor  
7.  redis-cli -h 127.0.0.1 -p 6379 info clients  
8.  redis-cli -h 127.0.0.1 -p 6379 info memory  
9.  \#休息100毫秒  
10. usleep 100000  
11. done

完整的日志文件：

[http://dl.iteye.com/topics/download/096f5da0-4318-332e-914f-6f7c7298ddc9][http_dl.iteye.com_topics_download_096f5da0-4318-332e-914f-6f7c7298ddc9]

部分日志：

Java代码   ![收藏代码][icon_star.png]

1.  =========================2015\-11\-06\_10:07:16===============================  
2.   \#Client-Monitor  
3.  id=7 addr=127.0.0.1:56358 fd=6 name= age=91 idle=0 flags=O db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=4869 omem=133081288 events=rw cmd=monitor  
4.  \# Clients  
5.  connected\_clients:502  
6.  client\_longest\_output\_list:4869  
7.  client\_biggest\_input\_buf:0  
8.  blocked\_clients:0  
9.  \# Memory  
10. used\_memory:174411224  
11. used\_memory\_human:166.33M  
12. used\_memory\_rss:161513472  
13. used\_memory\_peak:176974792  
14. used\_memory\_peak\_human:168.78M  
15. used\_memory\_lua:36864  
16. mem\_fragmentation\_ratio:0.93  
17. mem\_allocator:jemalloc-3.6.0

[http_carlosfu.iteye.com_blog_2254154]: http://carlosfu.iteye.com/blog/2254154
[c1763302-3ce3-3aa1-ab06-b79c9a5568f9.jpg]: /images/20220731/6acb56bc01944ce696363b166d4a12dc.png
[20306491-4a21-3c80-8f85-422486411458.jpg]: /images/20220731/0333a242b3e5460f98556b7506b875ae.png
[3c42bdf1-d1e1-3f69-91ff-d202216708bc.png]: /images/20220731/796ccaa2b7d641319760473b91562d61.png
[0fe3710a-48f9-37bc-b8d5-1512b09547ef.png]: /images/20220731/b8ca7d49b8484f988856542fe4c7a2e5.png
[95416cca-1bce-39b5-b53e-ff920e9df35c.png]: /images/20220731/7d6187f8d0a74aca997d7ed70944eb4b.png
[icon_star.png]: /images/20220731/3a81344f8364448e885c0db90198220b.png
[http_dl.iteye.com_topics_download_096f5da0-4318-332e-914f-6f7c7298ddc9]: http://dl.iteye.com/topics/download/096f5da0-4318-332e-914f-6f7c7298ddc9