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) Thanks.
