现象:
redis内存占满服务异常,没办法只能将redis中的数据flushall,然后刷新缓存,业务恢复。
但是问题要解决呀,等了半天,内存又上来了,抓儿挠筛想了一想,先看看redis中的慢查询长度。
经过判断是有量的大key值,导致的为了验证猜想,笔者百度了下,找到了两个redis rdb文件分析工具
pip3 install python-lzf 需要安装python、mysql,太麻烦了没弄,从而选择了第二种
通过rdb_bigkeys工具,很便捷的导出大KEY值的文件。
这是用go写的一款工具,分析rdb文件,找出文件中的大key,实测发现,不管是执行时间还是准确度都是很高的,一个3G左右的rdb文件,执行完大概两三分钟,直接导出到csv文件,方便查看,个人推荐使用该工具去查找大key。
公司内网太麻烦,搞了一台阿里云最便宜的主机,刚开始用1G的,弄到一版发现内存不够,也懒得查找了,销毁换一个2G内存的。
如下:避免踩坑比较好的教程。
Golang 安装教程源码安装_cnstartech的博客-CSDN博客_golang源码安装
环境具备后:
执行完成生成可执行文件rdb_bigkeys。
使用方法: ./rdb_bigkeys --bytes 1024 --file bigkeys.csv --sep 0 --sorted --threads 4 /home/redis/dump.rdb
/home/redis/dump.rdb修改为实际的文件路径
上述命令分析dump.rdb文件中大于1024bytes的KEY, 由大到小排好序, 以CSV格式把结果输出到bigkeys.csv的文件中,文件格式如图:
生产系统:
测试系统:
每列分别为数据库编号,key类型,key名,key大小,元素数量,最大值元素名,元素大小,key过期时间。
总结:最后发现大KEY值,对比测试环境和生产环境,交给开发改代码
后记:增加监控redis内存大小sheel脚本:cluster info
#!/bin/bash
cmd=/lin/opt/redis/bin/redis-cli
port=9736
host=localhost
unit=$cmd -h $host -p $port info memory |grep used_memory_human|cut -d: -f2|head -1|tr -d '\r'|awk -F '' '{print $NF}'
used_memory=$cmd -h $host -p $port info memory |grep used_memory_human|cut -d: -f2|head -1|tr -d '\r'
maxmemory=$cmd -h $host -p $port info memory |grep maxmemory_human|cut -d: -f2|head -1|tr -d '\r'
maxmemory_value=echo ${maxmemory%G}
if [ “$unit” == G ];then
used_memory_value=echo ${used_memory%G}
echo echo "scale=2; $used_memory_value*1024/($maxmemory_value*10.24)"|bc
elif [ “$unit” == M ];then
used_memory_value=echo ${used_memory%M}
echo echo "scale=2; $used_memory_value/($maxmemory_value*10.24)"|bc
elif [ “$unit” == K ];then
used_memory_value=echo ${used_memory%K}
echo echo "scale=2; $used_memory_value/1024/($maxmemory_value*10.24)"|bc
else
used_memory_value=echo ${used_memory%B}
echo echo "scale=2; $used_memory_value/1024/1024/($maxmemory_value*10.24)"|bc
fi
echo $unit
echo $used_memory
echo $used_memory_value
echo $maxmemory
echo $mem_fragmentation_ratio
#外加测试redis是否能成功写入
$cmd -h $host -p $port set monitor-test 1 >/dev/null
if [ $? = 0 ];then
echo redis is ok!
else
echo redis set error
fi