obukhov/redis-inventory: 分析redis内存使用情况的CLI工具


“ 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

点击标题见项目