> This is an issue described on the memcached documentation: > "...Unfortunately, slabs allocated early in memcached's process life > might over time be effectively in the wrong slabclass. Imagine, for > example, that you store session data in memcached, and memcached has > been up and running for months. Finally, you deploy a new version of > your application code, which stores more interesting information in > your sessions -- so your session sizes have grown. Suddenly, memcached > starts thrashing with huge amounts of evictions. What might have > happened is that since the session size grew, the slab allocator needs > to use a different slabclass. Most of the slabs are now sitting idle > and unused in the old slabclass. The usual solution is to just restart > memcached, unless you've turned on ALLOW_SLABS_REASSIGN..." > > We were having that same issue in many of our servers, and since > ALLOW_SLABS_REASSING is no longer supported the only thing we could do > was to restart the servers, which lead to a storm of cache misses and > other operational issues for us. > That's why we developed an experimental command named "drop_slab" > which when run just deletes all values in a slab class and deallocates > that memory returning it to the OS. > > My question are: > a) Has any of you run into this issue and if so how did you handle it? > b) Do you think this command is something you would use? If so I can > submit a patch. I'm planning to port it to version 1.6 (currently is > for version 1.4)
Yes, we're aware of this. Feel free to post your patch somewhere and talk about it. However what we end up using for mainline is taking more time to develop as it's difficult to do this automatically, correctly, for most users. It's coming up pretty soon in my TODO list though; we've been catching up on the backlog with 1.4. -Dormando
