heroku - almot 没有键的 Redis 高内存使用率

Question

我有一个由 heroku ( https://elements.heroku.com/addons/heroku-redis ) 托管的 redis 实例，并使用计划“Premium 1”

此redis 仅用于托管一个名为Bull ( https://www.npmjs.com/package/bull ) 的小型队列系统

即使几乎没有任何作业存储在 redis 中，内存使用率现在几乎达到 100%(允许的 100 Mo)。

我运行了一个 INFO此实例上的命令，这是重要的部分(如果需要可以发布更多内容):

# Server
redis_version:3.2.4

# Memory
used_memory:98123632
used_memory_human:93.58M
used_memory_rss:470360064
used_memory_rss_human:448.57M
used_memory_peak:105616528
used_memory_peak_human:100.72M
total_system_memory:16040415232
total_system_memory_human:14.94G
used_memory_lua:280863744
used_memory_lua_human:267.85M
maxmemory:104857600
maxmemory_human:100.00M
maxmemory_policy:noeviction
mem_fragmentation_ratio:4.79
mem_allocator:jemalloc-4.0.3

# Keyspace
db0:keys=45,expires=0,avg_ttl=0  

# Replication
role:master
connected_slaves:1
master_repl_offset:25687582196
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:25686533621
repl_backlog_histlen:1048576

我真的很难弄清楚如何使用 95 Mo 而只存储了 50 个对象。这些对象非常小，通常是一个包含 2-3 个包含小字符串和 id 的字段的 JSON

我试过了 https://github.com/gamenet/redis-memory-analyzer但是当我尝试运行它时它崩溃了

我无法获得转储，因为 Heroku 不允许这样做。

我在这里有点迷路，我可能错过了一些明显的东西，但我已经达到了我对 Redis 的理解的极限。

提前感谢您提供任何提示/指示。

编辑

我们不得不升级我们的 Redis 实例以保持一切正常运行，但问题似乎仍然存在。目前坐在 34 键/34 Mo

我试过了 redis-cli --bigkeys :

Sampled 34 keys in the keyspace!
Total key length in bytes is 743 (avg len 21.85)

9 strings with 43 bytes (26.47% of keys, avg size 4.78)
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00) 
24 hashs with 227 fields (70.59% of keys, avg size 9.46)
1 zsets with 23 members (02.94% of keys, avg size 23.00)

我很确定某处有一些开销，但我找不到什么。

编辑 2

我实际上是瞎子:used_memory_lua_human:267.85M在我第一次创建这篇文章时运行的 INFO 命令中，现在是 used_memory_lua_human:89.25M在新实例上

这看起来非常高，并且可以解释内存使用情况

Answer 1

你在数据库中只有 45 个键，所以你可以做的是:

1. 用KEYS * 列出所有键命令
2. 运行 DEBUG OBJECT <key>针对每个或多个键的命令，它将返回序列化长度，以便您更好地了解哪些键占用了大量空间。

另一种选择是运行 redis-cli --bigkeys所以它会显示最大的键。您可以通过特定于数据类型的命令查看 key 的内容 - 对于字符串，它是 GET命令，对于哈希它是 HGETALL等等。