>>> 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
