If I set key foo value 32 and run object idletime foo immediately, It doesn't return 0 or 1, it returns 191 instead. However, if I set the key foo value 10000 or any other string, it works well and returns 0 or 1 (depending on how long it takes me to input the command).
OBJECT IDLETIME should return how long it has been since the last time I get foo or set foo, It is improper to return 191 because I had just set the value of key foo.
Comment From: shenlongxing
You need to set maxmemory and maxmemory-policy to *-lru first.
Comment From: itamarhaber
Hello @ramwin
The screenshot is not enough to reproduce the issue (I tried, couldn't). It would be extremely helpful if you could attach a script that demonstrates it.
Comment From: ramwin
Hello @itamarhaber , I tried the command several times, and the error occurs randomly.
As you can see, I set the value after 1533000099 and get the value before 1533000107. The idletime of this key should not be more than 8 seconds (1533000107- 1533000099). However the idletime is 15, and sometimes it is even 191 or more than 3000 even I get the key immediately after I set the value.
I test it on my ubuntu server (ubuntu 16.04 and redis 3.0.6) the problem still exists.
I haven't learn the lua script yet. I will try to write a script to demonstrate it after learning the script. I hope these two illustrations above will give you more infomation and let you know how to reproduce the bug.
Comment From: ramwin
@shenlongxing Could you explain it more clearly and give some reference for me? The document says:
OBJECT IDLETIME
returns the number of seconds since the object stored at the specified key is idle (not requested by read or write operations). While the value is returned in seconds the actual resolution of this timer is 10 seconds, but may vary in future implementations. This subcommand is available when maxmemory-policy is set to an LRU policy or noeviction.
I read the default config, and the default maxmemory-policy is noeviction, so I think I met the requirements. Am I right? Here is my redis info, you can see more details if you want.
127.0.0.1:6379> info
# Server
redis_version:4.0.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:1bc80a08306a3efd
redis_mode:standalone
os:Linux 4.15.0-29-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:7.3.0
process_id:1274
run_id:a4ec2313839ab93c49a725761348af279feaf203
tcp_port:6379
uptime_in_seconds:90287
uptime_in_days:1
hz:10
lru_clock:6275388
executable:/usr/bin/redis-server
config_file:/etc/redis/redis.conf
# Clients
connected_clients:2
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
# Memory
used_memory:974824
used_memory_human:951.98K
used_memory_rss:3182592
used_memory_rss_human:3.04M
used_memory_peak:1066984
used_memory_peak_human:1.02M
used_memory_peak_perc:91.36%
used_memory_overhead:853680
used_memory_startup:782504
used_memory_dataset:121144
used_memory_dataset_perc:62.99%
total_system_memory:4083281920
total_system_memory_human:3.80G
used_memory_lua:41984
used_memory_lua_human:41.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:3.26
mem_allocator:jemalloc-3.6.0
active_defrag_running:0
lazyfree_pending_objects:0
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1533001880
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:458752
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
# Stats
total_connections_received:42
total_commands_processed:844
instantaneous_ops_per_sec:0
total_net_input_bytes:46503
total_net_output_bytes:286217
instantaneous_input_kbps:0.01
instantaneous_output_kbps:6.20
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:11
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:458
keyspace_misses:21
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:240
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
# Replication
role:master
connected_slaves:0
master_replid:b628264fea26a278ad2e960b8a810781eb95d5d1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
# CPU
used_cpu_sys:61.87
used_cpu_user:31.35
used_cpu_sys_children:0.03
used_cpu_user_children:0.05
# Cluster
cluster_enabled:0
# Keyspace
db0:keys=22,expires=1,avg_ttl=9604480
db1:keys=25,expires=25,avg_ttl=578770935
db4:keys=10,expires=9,avg_ttl=718539755
Comment From: shenlongxing
Redis uses a shared integer object[0-10000] to save space. If you set neither maxmemory nor maxmemory-policy(*-LRU), redis will encode all the objects which have the save integer value to a shared one. That means, these keys share the same value object. To identify this, you can test with none integer values.
Comment From: ramwin
@shenlongxing You are right. I tried and find it works well if I set the maxmemory and maxmemory-policy(*-LRU). To fix this, I have to set the both maxmemory and maxmemory-poilicy(volatile-lru), It will not work if you just set one parameter. What the original intention of this coimmand? I think the document is kind of wrong from the actual truth.
Comment From: shenlongxing
@ramwin Redis uses LRU/LFU to evict old data. You need to set both maxmemory and maxmemory-poilicy to achieve this. And the command is to fetch the lru value. So it is meaningless if you set improperly. I agree with that the document is a little confusing.
Comment From: creker
Stumbled upon this myself. As I see it, the documentation is wrong, not confusing. "this subcommand is available when maxmemory-policy is set to an LRU policy or noeviction". It doesn't work with noeviction. Either the part about noeviction should be removed completely or it should provide information how exactly it behaves when noeviction is used. I was planning to use this command to implement my own eviction algorithm (I don't want redis doing it for me automatically) but it looks like the command is useless in its current state.
Comment From: ramwin
The problem still exist, So I create a PR.
Comment From: itamarhaber
This can be closed as the issue was resolved via documentation.