obukhov/redis-inventory: 分析redis記憶體使用情況的CLI工具

banq發表於2021-08-27

“ Redis Inventory ”從Redis例項(或叢集)收集記憶體使用資訊,檢測關鍵模式,並以分層方式顯示記憶體使用情況。該名稱的靈感來自“磁碟清單 X”工具對磁碟使用情況進行類似的分析。
有人可能會爭辯說,與硬碟不同,快取伺服器不是持久儲存,那麼為什麼還要分析它的使用情況呢?是的,理論上,快取是完全短暫的,任何應用程式都應該能夠在“冷”狀態下啟動和使用它。
但實際上,在負載下,並不總是可以在沒有效能下降的情況下重新整理快取。
此外,如果應用程式使用 Redis 的方式存在問題,重新整理將只是暫時的緩解措施,因為一段時間後相同的問題會再次累積。
有時,您只是在 Redis 指標中看到一般的鍵數或記憶體消耗增加,但問題出在哪裡並不明顯,因此在沒有事先調查的情況下很難在程式碼中修復它。
在快取中看到的兩個最流行的問題是:快取鍵洩漏和忘記設定 TTL :
  • 您不小心向鍵Key新增了過於動態的內容時,就會發生鍵洩漏,例如時間戳或其雜湊。
  • 使用 TTL,您可能依賴應用程式來刪除它們,但在某些情況下它不會發生並且鍵將永遠保留在快取中。

在快速變化的大型應用程式中,這些問題很難追蹤。分析所有可能導致它的程式碼更改而不提示有問題的鍵可能需要數天時間。
 

工作原理
為了分析記憶體使用情況,該工具會掃描金鑰空間並使用MEMORY USAGE命令測量每個單獨的key大小。它構建了一個巢狀節點樹,類似於磁碟上的資料夾結構。但是我們如何將純字串鍵解釋為層次結構?在快取鍵中使用各種字首是很常見的,我們只需要反轉它。最簡單的方法是使用一組“:”字元並將字串分解為字串段的元組。然後將這些段中的每一個視為一個“資料夾”,構建一個節點樹.
這種結構在這種特殊情況下非常方便,原因有幾個:它節省記憶體,很容易在那裡新增key,並且在構建它的階段就可以聚合每個級別的使用資料。我們可以將聚合指標的容器附加到每個節點。當向樹新增新鍵時,我們將下降樹並在路徑中的每個級別新增值(記憶體使用或其他)。
 

命令

$ redis-inventory inventory <host>:<port> --output=table --output-params="padSpaces=2&depth=2&human=1"

輸出:

12:39PM INF Start scanning
+---------------------+----------+-----------+
| KEY                 | BYTESIZE | KEYSCOUNT |
+---------------------+----------+-----------+
|   dev:              |     2.9M |     4,555 |
|     article:        |   413.7K |       616 |
|     blogpost:       |   408.5K |       630 |
|     collections:    |   426.7K |       627 |
|     events:         |   391.2K |       614 |
|     friends:foobar: |   501.1K |       745 |
|     news:           |   388.8K |       593 |
|     user:           |     481K |       730 |
|   prod:             |     2.9M |     4,531 |
|     article:        |   397.1K |       614 |
|     blogpost:       |   409.4K |       627 |
|     collections:    |   374.7K |       560 |
|     events:         |   384.2K |       588 |
|     friends:foobar: |     503K |       755 |
|     news:           |   407.9K |       618 |
|     user:           |   492.3K |       769 |
+---------------------+----------+-----------+
12:39PM INF Finish scanning


點選標題見專案

相關文章