一台Redis服务器在很短的时间里消耗了几十个G的内存，最终因为SWAP而宕机。因为这台服务器的社会背景比较复杂，所以一时无法判断犯罪嫌疑人到底是谁。
一台Redis服务器在很短的时间里消耗了几十个G的内存，最终因为SWAP而宕机。因为这台服务器的社会背景比较复杂，所以一时无法判断犯罪嫌疑人到底是谁。
最开始的直觉是认为肯定有人保存了大体积的数据，于是问题就变成了找出哪些键占用的空间比较大，DBA同事用了redis-rdb-tools等工具来分析数据文件。可惜的是虽然找到了一些大体积的键，但最终都排除了嫌疑，问题似乎陷入了僵局。
在被直觉带入死胡同之后，我们开始调整调查的角度：即便一个键本身占用的空间并不大，但是如果相同模式的键数量很多的话，那么合计起来一样会占用大量空间，于是问题就变成了找出哪些相同模式的键占用的空间比较大。这次我不想用什么工具，而是打算在测试服务器上一边删除可疑键一边查看内存变化情况：
shell> /path/to/redis-cli keys foo:* | xargs /path/to/redis-cli del
悲催的是一运行这个命令服务器就挂了！因为数据太多了，所以KEYS受不了。此时应该使用SCAN，它有游标的概念，每次迭代只涉及很少的数据。
直接在命令行使用SCAN有些麻烦，于是我用了PHP：
<?php
$redis = new Redis();
$redis->setOption(Redis::OPT_SCAN, Redis::SCAN_RETRY);
$match = 'foo:*';
$count = 10000;
while ($keys = $redis->scan($it, $match, $count)) {
$redis->del($keys);
}
?>
在删除的同时注意监控内存变化情况，就能确认问题了：
shell> watch -d -n 1 '/path/to/redis-cli info | grep memory'
至于可疑键的获取，我是瞎蒙的，简单通过MONITOR或者SCAN获取采样数据即可，另外从此案例看，监控键总数的变化幅度是很重要的，从INFO里能拿到它。
©本文为清一色官方代发，观点仅代表作者本人，与清一色无关。清一色对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文不作为投资理财建议，请读者仅作参考，并请自行承担全部责任。文中部分文字/图片/视频/音频等来源于网络，如侵犯到著作权人的权利，请与我们联系（微信/QQ:1074760229）。转载请注明出处：清一色财经
微信扫码打赏 
支付宝扫码打赏 
