Was't that on the 1.0 branch ? I'm still running 0.8x ? @Peter: investigating a little more before answering. Thanks
2011/12/10 Edward Capriolo <edlinuxg...@gmail.com> > There was a recent patch that fixed an issue where counters were hitting > the same natural endpoint rather then being randomized across all of them. > > > On Saturday, December 10, 2011, Peter Schuller < > peter.schul...@infidyne.com> wrote: > >> Pool Name Active Pending Completed Blocked > All > >> time blocked > >> ReadStage 27 2166 3565927301 0 > > > > In general, "active" refers to work that is being executed right now, > > "pending" refers to work that is waiting to be executed (go into > > "active"), and completed is the cumulative all-time (since node start) > > count of the number of tasks executed. > > > > With the slicing, I'm not sure off the top of my head. I'm sure > > someone else can chime in. For e.g. a multi-get, they end up as > > independent tasks. > > > > Typically having pending persistently above 0 for ReadStage or > > MutationStage, especially if more than a hand-ful, means that you are > > having a performance issue - either capacity problem or something > > else, as incoming requests will have to wait to be services. Typically > > the most common effect is that you are bottlenecking on I/O and > > ReadStage pending shoots through the roof. > > > > There are exceptions. If you e.g. submit a really large multi-get of > > 5000, that will naturally lead to a spike (and if all 5000 of them > > need to go down to disk, the spike will survive for a bit). If you are > > ONLY doing these queries, that's not a problem per se. But if you are > > also expecting other requests to have low latency, then you want to > > avoid it. > > > > In general, batching is good - but don't overdo it, especially for > > reads, and especially if you're going to disk for the workload. > > > > -- > > / Peter Schuller (@scode, http://worldmodscode.wordpress.com) > > >
