我在生产中有20GB + rdb转储。 我怀疑有一组特定的钥匙膨胀它。 我想有办法总是从静态转储分析中发现前100个最大的对象,或者将它问到服务器本身,顺便说一下,它有7M对象。
像rdbtools这样的转储分析工具对此(我认为)真正常见的用例没有帮助!
我正在考虑编写一个脚本并使用“redis-cli调试对象”迭代整个键集,但我觉得必须有一些我缺少的工具。
答案 0 :(得分:65)
redis-cli添加了一个选项:redis-cli --bigkeys
基于https://gist.github.com/michael-grunder/9257326
的示例输出$ ./redis-cli --bigkeys
# Press ctrl+c when you have had enough of it... :)
# You can use -i 0.1 to sleep 0.1 sec every 100 sampled keys
# in order to reduce server load (usually not needed).
Biggest string so far: day:uv:483:1201737600, size: 2
Biggest string so far: day:pv:2013:1315267200, size: 3
Biggest string so far: day:pv:3:1290297600, size: 5
Biggest zset so far: day:topref:2734:1289433600, size: 3
Biggest zset so far: day:topkw:2236:1318723200, size: 7
Biggest zset so far: day:topref:651:1320364800, size: 20
Biggest string so far: uid:3467:auth, size: 32
Biggest set so far: uid:3029:allowed, size: 1
Biggest list so far: last:175, size: 51
-------- summary -------
Sampled 329 keys in the keyspace!
Total key length in bytes is 15172 (avg len 46.12)
Biggest list found 'day:uv:483:1201737600' has 5235597 items
Biggest set found 'day:uvx:555:1201737600' has 47 members
Biggest hash found 'day:uvy:131:1201737600' has 2888 fields
Biggest zset found 'day:uvz:777:1201737600' has 1000 members
0 strings with 0 bytes (00.00% of keys, avg size 0.00)
19 lists with 5236744 items (05.78% of keys, avg size 275618.11)
50 sets with 112 members (15.20% of keys, avg size 2.24)
250 hashs with 6915 fields (75.99% of keys, avg size 27.66)
10 zsets with 1294 members (03.04% of keys, avg size 129.40)
答案 1 :(得分:4)
redis-rdb-tools确实有内存报告,可以完全满足您的需求。它生成一个CSV文件,每个键都使用内存。然后,您可以对其进行排序并找到前x个键。
还有一个实验性的内存分析器,它开始做你需要的。它还没有完整,所以没有记录。但你可以尝试一下 - https://github.com/sripathikrishnan/redis-rdb-tools/tree/master/rdbtools/cli。当然,我也鼓励你们做出贡献!
答案 2 :(得分:2)
我是bash脚本的新手。我出来了:
for line in $(redis-cli keys '*' | awk '{print $1}'); do echo `redis-cli DEBUG OBJECT $line | awk '{print $5}' | sed 's/serializedlength://g'` $line; done; | sort -h
此脚本
redis-cli keys "*"
redis-cli DEBUG OBJECT
由于bash循环遍历每个redis密钥,因此这可能非常慢。您可能需要7m密钥才能将密钥的输出缓存到文件中。
答案 3 :(得分:1)
如果您的密钥遵循这种模式“A:B”或“A:B:*”,我写了一个工具,分析现有内容以及监视器的内容,例如命中率,获取/设置数量,网络流量,生命周期等。输出类似于下面的输出。
https://github.com/alexdicianu/redis_toolkit
$ ./redis-toolkit report -type memory -name NAME
+----------------------------------------+----------+-----------+----------+
| KEY | NR KEYS | SIZE (MB) | SIZE (%) |
+----------------------------------------+----------+-----------+----------+
| posts:* | 500 | 0.56 | 2.79 |
| post_meta:* | 440 | 18.48 | 92.78 |
| terms:* | 192 | 0.12 | 0.63 |
| options:* | 109 | 0.52 | 2.59 |
答案 4 :(得分:0)
尝试redis-memory-analyzer - 一种控制台工具,可以实时扫描Redis密钥空间,并按密钥模式聚合内存使用情况统计信息。您可以在生产服务器上使用此工具而无需维护。它会向您显示有关Redis服务中每个关键模式的详细统计信息。
您也可以通过所有或选定的Redis类型扫描Redis数据库,例如“string”,“hash”,“list”,“set”,“zset”。匹配模式也得到支持。
RMA还尝试按模式识别关键名称,例如,如果你有像'user:100'这样的键,'user:101'应用程序会在输出中选出常用模式'user:*',这样你就可以分析大多数内存您实例中的不良数据。