经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Redis » 查看文章
记一次线上Redis内存占用过高、大Key问题的排查
来源:cnblogs  作者:codest  时间:2024/5/11 8:55:10  对本文有异议

问题背景

在一个风和日丽的下午,公司某项目现场运维同学反馈,生产环境3个Redis的Sentinel集群节点内存占用都很高,达到了17GB的内存占用量。

稍加思索,应该是某些Key的Value数据体量过大,占用了过多的内存空间,我们在使用Redis的过程中,单个Value或者单个集合中的元素应该保证不超过10KB,已获取最佳的实践体验。

工具推荐

网上搜索了一番,关于分析大Key的工具还挺多,分为Redis官网工具和第三方工具。

经过一番比对,不同的工具都体验了一下,这里跳过工具之间的对比过程,直接给结论:redis data reveal

大家可以在releases中下载打包好的应用程序,这里也给个国内加速下载地址:蓝奏云

因为线上已经开启了Redis的RDB和AOF持久化策略,直接把RDB文件拉到本地。

如果没有开启RDB可以使用bgsave命令导出

执行RDB文件分析命令:

  1. chmod +x rdr-linux
  2. ./rdr-linux show -p 8099 dump.rdb

等待一会儿,程序会自动对RDB文件进行分析,分析完成后会在设置的端口打开web服务,我们的RDB文件有4GB,分析耗时大概5分钟,分析过程日志如下:

  1. start parsing...
  2. parse dump.rdb done
  3. parsing finished, please access http://{$IP}:8099

打开分析报告页面,查看到的queue:sdk:audit:log占用了17GB内存,经分析后发现是由于下游消费服务未部署导致队列数据积压所致:

通过Redis集群的Slave节点,再次查看对应的key大小(字节数):

  1. 127.0.0.1:9532> memory usage queue:sdk:audit:log
  2. (integer) 18124761989

至此,可以确定是该Key的原因导致Redis内存占用过高,因为这个key在该项目未使用到,所有对生产者做了优化处理,并删除线上Redis对应的key。

原文链接:https://www.cnblogs.com/changxy-codest/p/18181867

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号