【Redis】线上7000w+ keys && 16G内存100%的排查修复经历

  • 时间:
  • 浏览:4
  • 来源:万人牛牛_万人牛牛官网

基本使用全部都是默认的db 0, 都看keys肯能七千多万, 设置了过期的时间key只能173W..

亲戚亲戚朋友使用的老就是阿里云的redis, 亲戚亲戚朋友并不高并发应用, 主要也就是拿来做分布式锁和极少量的缓存, 基本不为甚还不能维护, 昨天下午时不时收到一封告警邮件,



线上redis内存使用400%, 瞬间神经绷紧感觉上控台确认.



这是另一个16G的线上实例, 平时只能400%



运行完成后内存使用率降到了 45%, 到这里内存大问题否是处里了.

跑了至少九个小时... 清理后来还剩了三千多万key, 内存倒是没为甚释放 其余的问了开发同学基本只能动. 使用率现在维持在400%以下暂时就不动了

好在亲戚亲戚朋友全部都是keyPrefix + 数字id后来的格式, 这里抽样400W看下比例,

先挂上bigkeys的命令



找开发同学确认下, 这里 ip.try.counter 后来是某个版本用来锁定用户ip尝试登陆的..居然没设置过期时间, 其余的key多有几个少都带了某些神奇的逻辑, 就基本这么动了....内心是崩溃的 这么先把某些清理掉

现在key不要 , 肯能直接keys波特率非常低下, 好在redis原生提供了SCAN, 还还不能迭代遍历, 写个简单的python脚本用scan每次扫描400W,把相关的keys给删掉.



发现有几个时不时时不时出现频率较高的大string key, 和开发同事确认, 是最近换成的redis缓存, 缓存时间为10天, 通知先关闭开关, 处里影响肯能运行的任务, 进redis暂时先删除有几个比较大的keys看看, 释放了极少量内存

说到底还是还不能规范使用者的习惯, 该设置过期时间的只能偷懒, 并非 有大内存需求的独立分配资源.