Eviction do it mvcc style

[jonathandelanders]

I would just like to say that this is one bad ass piece of software. Keep up the good work.

So as a feature request... it would be better for us if your LRU instead of removing the key actually just made it invisible similar to how postgres treats old rows. I'm not talking about versioning or anything just don't delete it but hide it from the results. And provide a "VACUUM" style command like postgres to clean up the expired keys. oh also, having an option to persist and replicate the LRU via RDB would be amazing as well. In other words the slave would inherit the LRU of the master which it received the RDB from. I understand some users wouldn't want it so making it an option would be cool.

I know thats a tall order but for my use case this would be an amazing feature. The inspiration comes from the fact that there is internal latency caused by the eviction itself slowing reads overall on the shard. Thank you.

[itamarhaber]

Hello @jonathandelanders

Just making sure that you are aware of the "new" (v4+) lazy/async features, including expiry's (lazyfree-lazy-expire configuration directive, defaults to no) - is that in use by the system/shard that is your muse?

Side thought/question: is lazyfree-to-be-freed memory reported somehow (aside from overall usage)?
EDIT: yes, INFO has the lazyfree_pending_objects metric.

[jonathandelanders]

wow that is exactly what I need i should have researched it first. I found the option in redis.conf but very little documentation. Where can i learn more about the option? Also I have been delaying my redis 4.x upgrade due to stability issues in the change log for quite some time. My 3.x cluster is very stable so i have not needed to upgrade.

[itamarhaber]

wow that is exactly what I need i should have researched it first.

I get that with most of my "original" good ideas :P

I found the option in redis.conf but very little documentation. Where can i learn more about the option?

I find the .conf file actually quite verbose in terms of documentation - it is usually my first stop, before going to the docs (and diving into the code laterz perhaps :P).

Reviewing the docs, I can see several shortcomings with how laziness is documented - I've opened a new issue for that just now (redis/redis-doc#991), so please feel free to contribute.

Some more info on lazy free:

• http://antirez.com/news/93
• http://antirez.com/news/110
• https://groups.google.com/d/msg/redis-db/5Kh3viziYGQ/58TKLwX0AAAJ

[jonathandelanders]

I agree also the redis.conf is quite verbose on everything. This is the first time i have noticed missing documentation. Anyways I admit i should have probably checked the changelog before posting. This is a good feature for certain use cases of redis.

[trevor211]

It seems that this issue can be closed. @itamarhaber @jonathandelanders

[itamarhaber]

Thanks @trevor211 - closing.