一台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裡能拿到它。