redis统计大key

–bigkeys

redis-cli -h <host> -p <port> -n <db> --bigkeys

这条命令会从指定的 Redis DB 中持续采样,实时输出当时得到的 value 占用空间最大的 key 值,并在最后给出各种数据结构的 biggest key 的总结报告:

user $ redis-cli -h myhost -p 12345 --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest hash   found so far ‘idx:同类项‘ with 1 fields
[00.00%] Biggest hash   found so far ‘idx:格点‘ with 3 fields
[00.00%] Biggest hash   found so far ‘idx:任意‘ with 14 fields
[02.29%] Biggest hash   found so far ‘idx:设‘ with 16 fields
[02.29%] Biggest hash   found so far ‘idx:4‘ with 69 fields
[04.45%] Biggest set    found so far ‘indexed_word_set‘ with 1482 members
[05.93%] Biggest hash   found so far ‘idx:c‘ with 159 fields
[11.79%] Biggest hash   found so far ‘idx:的‘ with 196 fields

-------- summary -------

Sampled 1484 keys in the keyspace!
Total key length in bytes is 13488 (avg len 9.09)

Biggest    set found ‘indexed_word_set‘ has 1482 members
Biggest   hash found ‘idx:的‘ has 196 fields

0 strings with 0 bytes (00.00% of keys, avg size 0.00)
0 lists with 0 items (00.00% of keys, avg size 0.00)
2 sets with 1710 members (00.13% of keys, avg size 855.00)
1482 hashs with 6731 fields (99.87% of keys, avg size 4.54)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

这条命令给出的 "big key" ,是值得去分析一下的。

原文地址:https://www.cnblogs.com/weifeng1463/p/10427054.html

时间: 2024-11-08 21:33:12

redis统计大key的相关文章

redis 删除大key集合的方法

redis大key,这里指的是大的集合数据类型,如(set/hash/list/sorted set),一个key包含很多元素.由于redis是单线程,在删除大key(千万级别的set集合)的时候,或者清理过期大key数据时,主线程忙于删除这个大key,会导致redis阻塞.崩溃,应用程序异常的情况. 一个例子 线上redis作为实时去重的一个工具,里面有6千万的用户guid,这么一个set集合,如果直接使用del删除,会导致redis严重阻塞. 1 10.1.254.18:6380> info

统计redis大key信息(前topN)

相关包下载链接 https://github.com/sripathikrishnan/redis-rdb-tools/releaseshttps://pypi.org/project/python-lzf/https://pypi.python.org/simple/redis/ 安装 pip install python-lzf-0.2.4.tar.gzpip install redis-2.10.6.tar.gzpip install rdbtools-0.1.12.tar.gz 解析re

redis过期键删除策略以及大key删除方法

今天遇到了一个前同事挖的坑,刷新缓存中商品信息时先让key过期,然后从数据库里取最新数据然后再放到缓存中,他是这样写的 redisTemplate.expire(CacheConst.GOOGS_PREFIX,1,TimeUnit.MILLISECONDS); 设置key过期为一毫秒,导致缓存中有时没有商品信息,因为在这一毫秒内有可能已经从数据库中取到了最新数据,并且又放到了缓存中,一毫秒过后key过期了,缓存中就没了商品信息. 正确的应该这样写redisTemplate.expire(Cach

如何提取Redis中的大KEY

工作中,经常有些Redis实例使用不恰当,或者对业务预估不准确,或者key没有及时进行处理等等原因,导致某些KEY相当大. 那么大Key会带来哪些问题呢? 如果是集群模式下,无法做到负载均衡,导致请求倾斜到某个实例上,而这个实例的QPS会比较大,内存占用也较多:对于Redis单线程模型又容易出现CPU瓶颈,当内存出现瓶颈时,只能进行纵向库容,使用更牛逼的服务器. 涉及到大key的操作,尤其是使用hgetall.lrange 0 -1.get.hmget 等操作时,网卡可能会成为瓶颈,也会到导致堵

拼多多面试真题:如何用 Redis 统计独立用户访问量!

阅读本文大概需要 2.8 分钟. 作者:沙茶敏碎碎念 众所周至,拼多多的待遇也是高的可怕,在挖人方面也是不遗余力,对于一些工作 3 年的开发,稍微优秀一点的,都给到 30K 的 Offer. 当然,拼多多加班也是出名的,一周上 6 天班是常态,每天工作时间基本都是超过 12 个小时,也是相当辛苦的. 废话不多说,今天我们来聊一聊拼多多的一道后台面试真题,是一道简单的架构类的题目: 拼多多有数亿的用户,那么对于某个网页,怎么使用 Redis 来统计一个网站的用户访问数呢? 使用 Hash 哈希是

拼多多后台开发面试真题:如何用Redis统计独立用户访问量

众所周至,拼多多的待遇也是高的可怕,在挖人方面也是不遗余力,对于一些工作3年的开发,稍微优秀一点的,都给到30K的Offer,当然,拼多多加班也是出名的,一周上6天班是常态,每天工作时间基本都是超过12个小时,也是相当辛苦的.废话不多说,今天我们来聊一聊拼多多的一道后台面试真题,是一道简单的架构类的题目:拼多多有数亿的用户,那么对于某个网页,怎么使用Redis来统计一个网站的用户访问数呢? 使用Hash 哈希是Redis的一种基础数据结构,Redis底层维护的是一个开散列,会把不同的key映射到

统计大文件里单词

转载统计大文件里,频数最高的10个单词,(C# TPL DataFlow版) 最近公司搞了一个写程序的比赛,要求从2G的文件里统计出出现频率最高的10个单词. 最开始的想法是使用字典树,后来发现字典树更适合用在找前缀上,在查找没有hash表效率高. 之后使用Hash表+DataFlow完成了功能,2G的文件处理在20秒以内(其实我有信心优化到10秒以内,但是太折腾了). 这是我的设计图: 为什么要形成那么多结果?因为我不想写锁,写锁会降低很多效率,而且也失去了线程的意义,每个线程做自己的工作,

Redis遍历所有key的两个命令 -- KEYS 和 SCAN

当我们需要遍历Redis所有key或者指定模式的key时,首先想到的是KEYS命令: KEYS pattern   官网对于KEYS命令有一个提示: KEYS 的速度非常快,例如,Redis在一个有1百万个key的数据库里面执行一次查询需要的时间是40毫秒 .但在一个大的数据库中使用它仍然可能造成性能问题,如果你需要从一个数据集中查找特定的 KEYS, 你最好还是用 Redis 的集合结构 SETS 来代替. KEYS命令使用很简单. redis> MSET one 1 two 2 three

高并发架构系列:Redis并发竞争key的解决方案详解

需求由来 1.Redis高并发的问题 Redis缓存的高性能有目共睹,应用的场景也是非常广泛,但是在高并发的场景下,也会出现问题:缓存击穿.缓存雪崩.缓存和数据一致性,以及今天要谈到的缓存并发竞争. 这里的并发指的是多个redis的client同时set key引起的并发问题. 2.出现并发设置Key的原因 Redis是一种单线程机制的nosql数据库,基于key-value,数据可持久化落盘.由于单线程所以Redis本身并没有锁的概念,多个客户端连接并不存在竞争关系,但是利用jedis等客户端