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