When I scan entire redis instance using redis-cli --bigkeys following shortened result is returned
-------- summary -------
Sampled 241145 keys in the keyspace!
Total key length in bytes is 13013217 (avg len 53.96)
Biggest string found 'celery-task-meta-52b14b66-b924-4c40-b7dc-7d5b9b633470' has 6510 bytes
**Biggest list found 'celery9' has 156519 items**
Biggest set found '_kombu.binding.celeryev' has 52 members
Biggest hash found 'unacked' has 544 fields
Biggest zset found 'unacked_index' has 550 members
As you can see my biggest list is celery9 with length 156519. I am using only one keyspace
127.0.0.1:6379> info keyspace
# Keyspace
db0:keys=256672,expires=256659,avg_ttl=1701804
But when I connect to redis instance using redis-cli or even with redis connector from python and run following commands
127.0.0.1:6379> get celery9
(nil)
127.0.0.1:6379> llen celery9
(integer) 0
127.0.0.1:6379>
nil or zero is returned as if there was no key celery9.
So the question is, how to get correct length of this key? All others keys are working perfectly
Are you certain that the list hasn’t somehow been deleted between the time you run --bigkeys and the time you check the value from redis-cli? You might also be able to use the output of the MONITOR command to see what’s going on with this key.
Not key was not deleted. I was monitoring my instance before using the same command you suggested but without result. Even key was changing its size in another window.
But I found out without grep, that in reality it is not celery9 (btw application LPUSH to it as celery9) but key is “celery\x06\x169”.
This may actually be a kind of bug in the Redis bigkeys commands, where there’s an issue displaying the key name if it has unprintable characters (as in the \x06). It might be worth filing an issue: https://github.com/redis/redis/issues