redis做系統快取，歷史原因快取策略和快取內容不太適應增長的業務量，死皮賴臉扛著dba各種dissn個日日夜夜後決定清理一波殭屍。
但將無用的key刪除後，並沒有真正的釋放記憶體，檢視redis的相關文件，也沒有釋放記憶體的相關命令。看著儀錶盤的百分比甚是撓頭。。。
查了些資料了解了下，改日再請教請教dba大大們。。。
官方已經說了具體原因
概括了點內容：
這不是redis本身的問題，redis本身確實已經呼叫free釋放這些記憶體。這應該是使用的底層c執行時的問題。
當鍵被刪除時，redis並不總是釋放(返回)記憶體到作業系統。這並不是redis的特別之處，但大多數malloc()實現都是這樣工作的。
例如乙個例項有5gb的資料,然後刪除相當於2gb的資料,used_memory_rss可能仍會5 gb左右。這是因為底層分配器不能輕鬆地釋放記憶體。例如，通常將刪除的大多數鍵分配到與其他仍然存在的鍵相同的頁面中。
然而分配器是聰明和能夠重用空閒塊的記憶體,所以在你釋放2 gb的5 gb的資料集,當你開始再次增加鍵,您將看到used_memory_rss保持穩定而不會再增加很多。分配器基本上是嘗試重用以前(邏輯上)釋放的2gb記憶體。
就glibc來說，在分配大於128k的記憶體時使用mmap，而使用brk/sbrk在heap中分配小記憶體。通過mmap申請的內存在呼叫free後能馬上返還給系統，而heap中的記憶體就不一定，除非釋放的記憶體是heap中連續的大塊。
redis本身沒有記憶體管理機制，只有乙個使用量的統計功能 。每次需要建立物件，都是直接呼叫malloc申請，而redis中的物件基本都比較小，所以基本都是在heap中的記憶體。
mark乙個鏈結，全英文，改日研讀
解決方案
通過原因可以知道，我們其實不用去關注。
特別是我們定義了maxmemory後，並且定義了maxmemory_policy，那麼即使記憶體滿了，redis也會按照淘汰機制方案，清除一些不需要的key，來存放新的key。
但是如果已經影響到系統記憶體使用了，也有下面三種方案：
看了解決方案，然後還是去請教dba大大吧。。。。
redis批量刪除資料
redis本身未提供批量刪除的功能，但我們可以使用下面的技巧批量刪除全部或指定格式的資料。刪除以test開頭的所有key值 redis cli h p 埠 a 密碼 keys test xargs redis cli h p 埠 a 密碼 del 如果是刪除localhost的redis資料，且未設...
oracle刪除資料後的恢復
要達到刪除資料，有以下幾種方式都可以 1 delete 2 drop乙個表 3 truncate乙個表 重要的不是怎麼刪除乙個表，而是誤刪除資料後怎麼立即恢復 不考慮全庫備份和利用歸檔 日誌 對於delete方法,可以利用oracle提供的閃回方法 如果在刪除資料後還沒做大量的操作 只要保證被刪除資...
oracle刪除資料後的恢復
要達到刪除資料，有以下幾種方式都可以 a 確定刪除資料的時間 在刪除資料之前的時間就行，不過最好是刪除資料的時間點 b 用以下語句找出刪除的資料 select from 表名 as of timestamp to timestamp 刪除時間點 yyyy mm dd hh24 mi ss c 把刪除...