Redis記憶體占用過大如何分析?

2022-07-03 06:33:14 字數 1250 閱讀 2918

前幾天突然收到redis記憶體超標的報警,趕緊看了下監控,看到這個曲線吸了一口涼氣,這增長速度也太快了,需要快速定位出問題,不然就要爆了。

這個redis由多個應用共享,我們就有2個問題需要解決:

首先要找出是哪個應用在占用redis記憶體;

其次是到底是某個key值太大,還是數量太多引起的?

為解答這2個問題,首先通過redis-cli進入redis看看,立馬發現對這2個問題基本束手無策,這裡面總共有20w以上的鍵,不太可能乙個個過過去,redis-cli本身也不支援按大小對key值排序,也不支援對鍵值分組統計,我們需要換個思路。看看有沒有第三方的redis記憶體分析工具。經過一番搜尋,最終找到了乙個完全滿足要求又易用的工具——redis insight,我也同時對比了其他純命令列工具,比如redis-rdb-tools,rma等等,但是發現執行速度慢很多,結果也不直觀。

下面我們看下使用redis insight如何解決這個問題。

等待分析完成後,直接進到keyspace summary,先確定是哪個應用在占用redis記憶體。一般來說,不同應用會使用不同的命名空間,因此根據命名空間可以確定出具體是哪個應用在占用記憶體。如下圖所示,第1個佔了6.45gb,顯然就是這個應用了。第1個問題解決了。

進入到該命名空間內部,看下它的具體鍵值情況按記憶體分布的情況,最大的是55m,離6.3g還遠著。這時注意到3~4mb的鍵比較多,這個不太正常,正常應用都不會存這麼大的,於是統計了下1m以上的鍵值,有幾千個,差不多就是占用了6g多,所以既不是某個鍵值特別大,也不是小空間的鍵數特別多引起的,而是空間占用偏大的鍵數量多導致的。接著挑幾個具體的鍵,看下它們的鍵的具體內容是什麼特徵。其中乙個鍵的內容如下:

經過推測,應該是應用的session。又抽了幾個,都是相同的內容,可以斷定應該是應用的session儲存了不合理的資訊,於是去應用那邊結合**排查,果然是存在這個問題。**調整後,這個問題就消失了。

《redis使用rdb檔案恢復資料》

《怎麼分析和優化redis的記憶體使用率》

《the-top-6-free-redis-memory-analysis-tools》

SVN CPU記憶體占用過大問題

安裝了svn後會有乙個tsvncache.exe的程序駐留記憶體,這個程序會定時地去掃瞄subversion管理的資料夾 檔案是否被修改了,一旦發現有更新,那本地的這些有更新的檔案 資料夾就會被更新,這個動作不僅會占用10 85mb左右的記憶體,而且也會在執行的瞬間占用超過cpu 50 的負載。對於...

mac 硬碟占用過大?

1 docker的快取 預設64gb 這個檔案特別大 users library containers com.docker.docker data vms 0 data docker.raw 可以圖示上面 preference disk 中縮小預設的disk size 3 系統部分 除了zz目錄 ...

buff cache 占用過大問題

什麼是buffer cache buffer cache則主要是設計用來在系統對塊裝置進行讀寫的時候,對塊進行資料快取的系統來使用。這意味著某些對塊的操作會使用buffer cache進行快取,比如我們在格式化檔案系統的時候。一般情況下兩個快取系統是一起配合使用的,比如當我們對乙個檔案進行寫操作的時...