Expires hash active rehashing

[Daniel Mezzatto]

The "activerehashing" config states the following:

# Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in

# order to help rehashing the main Redis hash table (the one mapping top-level

# keys to values). The hash table implementation Redis uses (see dict.c)

# performs a lazy rehashing: the more operation you run into an hash table

# that is rehashing, the more rehashing "steps" are performed, so if the

# server is idle the rehashing is never complete and some more memory is used

# by the hash table.

# 

# The default is to use this millisecond 10 times every second in order to

# active rehashing the main dictionaries, freeing memory when possible.

#

# If unsure:

# use "activerehashing no" if you have hard latency requirements and it is

# not a good thing in your environment that Redis can reply form time to time

# to queries with 2 milliseconds delay.

#

# use "activerehashing yes" if you don't have such hard requirements but

# want to free memory asap when possible.

But it looks like this config only applies to the "dict" hash (keyspace), not to the "expires" hash. Is that right?

We are having some performance issues when a sudden spike of EXPIRE commands is receive by Redis. It seems that a lot of rehashing steps are performed, which lead to a queries with a high delay.

Our Redis instances reports roughly this:

expired_keys:130000

db0:keys=320000,expires=20000

Any thoughts / advices?

[Didier Spezia]

>> But it looks like this config only applies to the "dict" hash (keyspace), not to the "expires" hash. Is that right?

Active rehashing applies to both "dict" and "expires".

See function incrementallyRehash in redis.c

>>expired_keys:130000

>>db0:keys=320000,expires=20000

>>

>>Any thoughts / advices?

20000 items to be expired ... it is not a lot ... and your global number of keys in not that high.

Even in case of aggressive rehashing, I don't think it can produce significant latency.

 

Regards,

Didier.