I was just playing with an underdocumented script, called memcached- tool, which is in the memcached source tree in the scripts subdirectory. It has a 'dump' command implementation that uses stats cachedump in the way that Josh described.
I'm glad Josh shared his usage example -- stats cachedump is for offline debugging and offline analysis only. Most importantly, the stats cachedump message will lock up memcached during it's processing. Oh, and as Josh alluded to, you'll get only a subset (< 2MB worth) of keys per slabclass due to output buffer limits. Finally, I found a situation where memcached-tool hangs on missing keys. A fixed version's at http://github.com/steveyen/memcached/blob/40cae8abeb19e98a780a3cf8b218f4a487d750f6/scripts/memcached-tool Best, steve On Jan 29, 3:43 pm, Josh Snyder <j...@admob.com> wrote: > >>> My next question is stats cachedump. Are people using that feature?? > >>> Personally I would like to kill that as a stats subcommand, and try to > >>> think > >>> of a better way we may help developers to try to debug their application. > > >> stats cachedump can be very helpful. Here's how we use it (albeit rarely): > > >> We're taking a production machine down for other reasons. There's some > >> question about our cache utilization. We run stats cachedump, parse > >> the keys (which are all nicely prefixed), and get a nice picture of > >> which portions of our cached data live in which slabs, how numerous > >> they are, how much size they take up, etc. That sort of data -- a high > >> level snapshot of the steady state of a production system -- can be > >> very valuable, and cachedump makes it reasonably easy to grab, without > >> writing any new code. In fact, if anything, I'd like to keep the > >> command but remove the buffer limit... > > > I would prefer if we wrote this as a new and separate command and not as a > > subcommand to stat... > > Sounds reasonable to me -- as long as there's some way to get at this > data, it doesn't much matter how (to me, anyway). In fact, explicit > support for this would be much better, since one would not then have > to iterate over all the slabs. > > The key thing, to my mind, is to be able to get a dump of every item > in the cache (or at the least a representative sample). It doesn't > have to be performant in the slightest. Here's how I would rank the > per-item attributes: > > Crucial: > * key > * value size > > Nice to have: > * storage details as relevant (e.g. for the slab allocator, which slab > it was in) > * value > * expiry > * flags as set by the client? > > Best, > -josh
