maxmemory-samples what does't this setting mean?

2,153 views
Skip to first unread message

Mikhail Mikheev

unread,
Jun 3, 2011, 10:39:52 AM6/3/11
to Redis DB
Hi everyone,

It's evening already and I can't understand completely from the
comments in redis.conf what the 'maxmemory-samples' setting means. It
would be much appreciated If you wrote a couple of sentences what it
is.

Here is the comment:
# LRU and minimal TTL algorithms are not precise algorithms but
approximated
# algorithms (in order to save memory), so you can select as well the
sample
# size to check. For instance for default Redis will check three keys
and
# pick the one that was used less recently, you can change the sample
size
# using the following configuration directive.
#
# maxmemory-samples 3

What excatly I can't understand is what samples are. How I got the
idea is with default setting Redis checks only three keys from the
internal hash table and select the least recently used from them or it
splits the whole set of keys on 3 keys length regions and choose the
least recently used key from each region and evicts one key from each
region until it is enough room to place new value into memory. It
seems not logical for me so that is why i'm asking for explanation.

Tons of thanks in advance!

Salvatore Sanfilippo

unread,
Jun 3, 2011, 11:54:51 AM6/3/11
to redi...@googlegroups.com
On Fri, Jun 3, 2011 at 4:39 PM, Mikhail Mikheev <michail...@mail.ru> wrote:
> It's evening already and I can't understand completely from the
> comments in redis.conf what the 'maxmemory-samples' setting means. It
> would be much appreciated If you wrote a couple of sentences what it
> is.

When Redis is using more than the configured max memory setting, it
needs to evict some key.
In order to do so it selects N random keys, and checks the one with
the older LRU timestamp. This key is removed.

I said redis selects *N* random keys. That "N" is exactly the
maxmemory-samples parameter, that is set to three by default.

Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele

Mikhail Mikheev

unread,
Jun 6, 2011, 3:43:43 AM6/6/11
to Redis DB
Salvatore, thanks a lot!

Now it is clear enough. And here is just a couple of little questions:

1) If it is not enough to evict just one key it repeats what you
wrote, right? (select N random keys and chose one of them to evict)
I'm pretty sure it does, but just to make sure.

2) And all of that applies for both volatile-lru and allkeys-lru
policies (and volatile-ttl also), rigth? I'm just interested how it
works because AFAIK most caches implementation stores a queue of keys
and moves the key on top of that when it is accessed in order to
implement LRU algorithm but I read somewhere that Redis instead stores
TTL (or something like that). So how do you choose N random keys from
only volatile keys or all keys depeding on which policy is configured.
That is, in case volatile-lru is configured you just choose N random
keys and check if all of them are volatile and choose a few keys more
if some of the keys are not volatile again and again until N volatile
keys are chosen. Or do you have some smarter logic?

On Jun 3, 7:54 pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:

Mikhail Mikheev

unread,
Jun 6, 2011, 3:48:23 AM6/6/11
to Redis DB
Salvatore, thanks a lot!

Now it is clear enough. And here is just a couple of little questions:

1) If it is not enough to evict just one key it repeats what you
wrote, right? (select N random keys and chose one of them to evict)
I'm pretty sure it does, but just to make sure.

2) And all of that applies for both volatile-lru and allkeys-lru
policies (and volatile-ttl also), rigth? I'm just interested how it
works because AFAIK most caches implementation stores a queue of keys
and moves the key on top of that when it is accessed in order to
implement LRU algorithm but I read somewhere that Redis instead stores
TTL (or something like that). So how do you choose N random keys from
only volatile keys or all keys depeding on which policy is configured.
That is, in case volatile-lru is configured you just choose N random
keys and check if all of them are volatile and choose a few keys more
if some of the keys are not volatile again and again until N volatile
keys are chosen. Or do you have some smarter logic?

On Jun 3, 7:54 pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages