前幾天突然收到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進行快取，比如我們在格式化檔案系統的時候。一般情況下兩個快取系統是一起配合使用的，比如當我們對乙個檔案進行寫操作的時...