Redis ttl payload memory size - redis

I am wondering how much memory space does enabling TTL for a particular key will use. To be more precise, if I enable TTL for a key, how much memory does this settings will consume and how to check the memory consumption by setting such TTL?

TTL doesn't consume any extra space. The internal memory allocation for it is performed when creating a key, whether you use it or not.
P.S. IIRC, the TTL is a 64-bit variable, so it "costs" 8 bytes.

Related

Redis key eviction clarification

Im evaluating the opensource redis and came to a confusion regarding the max memory settings and eviction policies.
Suppose,my maxmemory is 4GB and data size also 4GB and set maxmemory-policy allkeys-lru. What my question is when new keys are written to Redis the evicted keys will be lost from system permanently or will be stored in disk so that I can reuse when ever required.
Thank you,

Large amount of redis keys are evicted unexpectedly even though memory not reach max configuration

I am experiencing a very strange case happen in production with redis, a large amount of redis keys are evicted unexpectedly even though memory not reach max configuration.
Current redis setting is max mem = 7GB, volatile-ttl.
Most of the keys are set a TTL when store to Redis.
Below graph showing a large drop in redis key eventhough memory at the time was only 3.5GB (<< 7GB)
According to my understanding, Redis would evict keys only when memory reach max-mem. And even when it does, it will only drop keys gradually according to the need for inserting new keys.
Thank you very much!

Redis TTL vs "allkeys-lru" eviction policy

I have a question on Redis cache's behavior. Kindly clarify -
Say, for a key "xyz" if the TTL is set to 15 minutes.
And, if its eviction policy in server level is set to "allkeys-lru". Does expired items(cause of TTL) EXPIRE or WAIT until the memory is full?
The eviction policy only applies to what happens when you exceed the max memory. As long as you're within your memory limits, volatile keys will expire when they should be expired.
Once your memory is full, an LRU algorithm kicks in, evicting least recently used keys. In allkeys-lru, it doesn't matter whether a key is expired or not and what is the TTL - the least used items will be evicted. In volatile-lru only expiring keys will be evicted using this algorithm.

Impact of increasing the MAXMSGL parm of a receiver channel

What is the impact of increasing the MAXMSGL parm of a receiver channel?" Does it automatically increase the amount of memory allocated for the channel, regardless of the size of the messages that flow across the channel? For a cluster-receiver channel, which typically supports multiple channel instances, does it increase the memory allocation for each channel instances? (example: if the channel is supporting 10 connections, and we increase MAXMSGL from 4MB to 100MB, does it increase memory usage from 40MB to 1GB?
We are using MQ v7.5.0.3 on AIX.
Thanks!!
The short answer is no. If the message size is 100KB that flows across the channel then you will see no difference. On the other hand, if the message size jumps to 100MB then the memory size will increase but I don't believe it will hit 1GB.

How to make Redis choose LRU eviction policy for only some of the keys?

Is there a way to make Redis choose a LRU (least recently used) eviction policy for only specific keys? I want a set of keys to be persistent and never be evicted if there's not enough memory. On the other hand, I want another set of keys to be freely evicted if there's low memory.
Redis has an eviction policy which might be good for your case.
You can set the maxmemory-policy to volatile-lru which causes Redis to:
remove the key with an expire set using an LRU algorithm
Which means that keys that are not set with TTL are not volatile, and therefor will not be evicted but keys that have TTL will be removed by Least-Recently-Used order.
Actually, volatile-lru is the default policy, so all you have to do is to make sure TTL is set for the keys you are willing to lose when memory is getting full.
Edit: Since version 3.0 the default eviction policy is "noeviction". (changelog)