UPDATED:如果版本够,记得试试 redis-cli 的 bigkeys 选项
如果 MySQL 数据库比较大的话,我们很容易就能查出是哪些表占用的空间;不过如果 Redis 内存比较大的话,我们就不太容易查出是哪些(种)键占用的空间了。
有一些工具能够提供必要的帮助,比如 redis-rdb-tools 可以直接分析 RDB 文件来生成报告,可惜它不能百分百实现我的需求,而我也不想在它的基础上二次开发。实际上开发一个专用工具非常简单,利用 SCAN 和 DEBUG 等命令,没多少行代码就能实现:
<?php $patterns = array( 'foo:.+', 'bar:.+', '.+', ); $redis = new Redis(); $redis->setOption(Redis::OPT_SCAN, Redis::SCAN_RETRY); $result = array_fill_keys($patterns, 0); while ($keys = $redis->scan($it, $match = '*', $count = 1000)) { foreach ($keys as $key) { foreach ($patterns as $pattern) { if (preg_match("/^{$pattern}$/", $key)) { if ($v = $redis->debug($key)) { $result[$pattern] += $v['serializedlength']; } break; } } } } var_dump($result); ?>
当然,前提是你需要提前总结出可能的键模式,简单但不严谨的方法是 MONITOR:
shell> /path/to/redis-cli monitor | awk -F '"' '$2 ~ "ADD|SET|STORE|PUSH" {print $4}'
此外,需要注意的是:因为 DEBUG 返回的 serializedlength 是序列化后的长度,所以最终计算的值小于实际内存占用,但考虑到相对大小依然是有参考意义的。
对此方法给个赞!
我实际测试了一下这个方法,以list为例,在使用同种编码的时候,例如都使用ziplist或linkedlist,统计结果是有意义的。
我现在遇到了一个问题就是不同编码的时候,list所占用的内存是非线性的,linkedlist编码所占用的内存远大于ziplist编码。
那么此时若是想知道list究竟占了多少内存,计算就比较困难。
我用了一个非常土的办法,将两份数据分别存到不同的空数据库,然后info查看信息。这么土的办法,我真是哭了 *_*
在redis-2.8中,redis-cli有个很好用的参数,–bigkeys,可以找出一些比较大的key和key的长度统计。我的博文,http://mdba.cn/?p=775
eg:
/apps/svr/redis/bin/redis-cli -p 6382 –bigkeys
Sampled 59808 keys in the keyspace!
Total key length in bytes is 4039873 (avg len 67.55)
Biggest string found ‘c_test::2378763’ has 902901 bytes
59808 strings with 401185727 bytes (100.00% of keys, avg size 6707.89)
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)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
恩,bigkeys 很赞,适合查那种较大的 Key,本文介绍的方法适合查那种单个 Key 不大,但是数量很多的情况。
好文
这几个东西线上的环境敢用嘛?
Pingback引用通告: 如何遍历线上redis所有key | 诺亚方舟