Redis异常问题分析黄金一分钟

背景

同事发现一个环境redis比较卡顿,导致业务比较难以开展.
问题是下午出现的. 六点左右找到我这边.
想着帮忙看看, 问题其实没有定位完全, 仅是发现了一个可能的点. 

所以想记录一下, 备查

步骤

登录redis进行查看
处理的过程: 

1. info memory  查看内存使用情况. 
本次问题的表征, memory的值超级大, 到了六七十G.
同事导出dump之后执行导入, 发现只有 2G的内存
这一块是一个没有解决的问题, 初步怀疑可能某些操作触发了redis的bug导致. 
还关注到内存的碎片率其实很低. 

2. info client 以及 dbsize
确认client数量以及dbsize的数量.  

3. slowlog get 10 
查看慢日志的情况. 有没有特别多. 
这个问题比较重要和关键, 如果出现了很慢的查询信息, 可能会导致比较严重的问题. 
这次发现是一个set的键值对 177mb 然后多次执行了 smember的处理. 

4. 使用rdr工具分析dump文件
查看键值对的大小情况. 

5. 使用rdb将dump文件分析成key信息. 
可以作为最终解决方法进行分析处理.

总结

暂时没有搞定内存的问题.  还需要继续分析
但是在save时时间很久 800mb的dump文件就要耗时 40多秒, 磁盘性能非常堪忧
客户这边又有aof, 感觉可能会严重影响性能. 
关于内存部分
建议下次出问题时从pod层进行一下查看
看看具体的内存占用和使用情况, 结合dump进行协同分析. 

redis的内存使用量, 改天需要继续进行一下学习与研究.