今天解決一個redis內存使用量大的問題。和大家分享一下。
有一個歷史遺留系統A，因為一些業務原因，申請了很大的redis內存。從40G一路加到了80G。但是仍然經常告警，達到了max_memory。
聯系系統用戶，刪除了大量數據。查看內存，仍然處于緊張狀態。
查了一些資料。
redis的內存使用構成
我們查詢redis的內存使用：
info memory
used_memory Redis：分配器分配的內存量，也就是實際存儲數據的內存總量
used_memory_human：以可讀格式返回 Redis 使用的內存總量
used_memory_rss：從操作系統的角度，Redis進程占用的總物理內存
used_memory_peak：內存分配器分配的最大內存，代表used_memory的歷史峰值
used_memory_peak_human: 以可讀的格式顯示內存消耗峰值
used_memory_lua:Lua引擎所消耗的內存
mem_fragmentation_ratio:used_memory_rss /used_memory比值，表示內存碎片率
mem_allocator:Redis 所使用的內存分配器。默認: jemalloc
計算公式如下：
used_memory = 自身內存+對象內存+緩沖內存+lua內存
used_rss = used_memory + 內存碎片
如下圖所示：
3.1.2 內存分析
- 1） 自身內存：一個空的Redis占用很小，可以忽略不計
- 2） kv內存：key對象 + value對象
- 3） 緩沖區：客戶端緩沖區(普通 + slave偽裝 + pubsub)以及aof緩沖區(比較固定，一般沒問題)
- 4） Lua：Lua引擎所消耗的內存
內存突增常見問題
- 1） kv內存：bigkey、大量寫入
- 2） 客戶端緩沖區：一般常見的有普通客戶端緩沖區(例如monitor命令)或者pubsub客戶端緩沖區
可能出現的問題排查
- 1） bigkey？
redis --bigkeys：可以對redis整個 keyspace 進行統計（數據量大時采樣，調用 scan 命令），尋找每種數據類型較大的 keys，給出數據統計 redis-cli --bigkeys -i 0.1 -h 127.0.0.1
- 2） 鍵值個數增加？
- 3） 客戶端緩沖區
如果是因為緩沖區問題，會從info clients找到明顯問題。重點觀察是否明顯的omem大于0的情況。
- 4） Redis的kv哈希表做了 rehash
問題解決
本次遇到的問題是客戶端緩沖區問題，使用如下命令
redis-cli -c -h x.x.x.x -p 6398 -a xxxx client list | grep -v 'omem=0'
查詢緩沖器非0的客戶端
發現有一個客戶端持有了大量內存緩沖。將對應的應用重啟后。內存使用量一下子降下來了。
