On Jun 11, 2008, at 13:24, Josef Finsel wrote:
I agree that this seems to conflict with the idea of how memcache is generally used. But the suggestion your making still wouldn't guarantee that the item would stay in cache since it could be that there are no other lower priority LRU items to be dumped.
I meant to imply that you could have a priority that means what the original request was -- to not have it be eligible for LRU eviction.
On Jun 11, 2008, at 13:30, dormando wrote:
Thinking it through, I'm not actually entirely sure how priority without a guarantee on evictions would be of much use. if an item is that important, but not accessed very often, is it really that important?
Well, this was my initial thought, but frequency of access is relative. The LRU can evict something that's accessed a couple times a second if you're flooding the thing with sets (which would otherwise be considered more eligible for LRU eviction).
If the number of values are small, that smells more like a database summary table entry with its own cache than a server modification. That would be tolerant to any sort of cache failure (ie; upgrades). Building in minor guarantees is asking for pain.
I don't know that I could say that very broadly. I know I've got items I'd rather have expire before others in an LRU.
I do agree that overuse would mean people would start getting OOM errors again and would likely cause confusion. More stats would need to accompany such a thing and you'd never really prevent someone from doing something dumb.
Mixing instances with -M seems like it'd create a lot of overhead. I think having something that's almost, but not entirely -M would be better. Imagine adding a value to -M that allows you to specify how many items (per slab or whatever) could be escalated to a ``never LRU evict'' priority.
-- Dustin Sallings
