dustin at spy.net
Wed Jun 11 21:20:49 UTC 2008
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
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
More information about the memcached