> Hi Guys, > im running a specific case where i don't want (actually can't have) to have > evicted items (evictions = 0 ideally)... now i have created some simple > algo that lock the cache, goes through linked list and evicts items... it > makes some problems, like 10-20ms cache locks on some cases. > > Now im thinking about going through each slab memory (slabs keep a list of > allocated memory regions) ... looking for items, if expired item is > found, evict it... this way i can go eg. 10k items or 1MB of memory at a time > + pick slabs with high utilization and run this "additional" eviction > only on them... so it'll prevent allocating memory just because unneded data > with short TTL is occupying HEAD of the list. > > With this linked list eviction im able to run on 2-3GB of memory... without > it 16GB of memory is exhausted in 1-2h and then memcached starts to > kill "good" items (leaving expired ones wasting memory)... > > Any comments? > Thanks.
you're going a bit against the base algorithm. if stuff is falling out of 16GB of memory without ever being utilized again, why is that critical? Sounds like you're optimizing the numbers instead of actually tuning anything useful. That said, you can probably just extend the slab rebalance code. There's a hook in there (which I called "Angry birds mode") that drives a slab rebalance when it'd otherwise run an eviction. That code already safely walks the slab page for unlocked memory and frees it; you could edit it slightly to check for expiration and then freelist it into the slab class instead. Since it's already a background thread you could further modify it to just wake up and walk pages for stuff to evict. -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
