No, CM is not exposed to nodetool yet. (You should really be putting metrics into a real monitoring system rather than relying on nodetool. Some example munin plugins are at http://github.com/jbellis/cassandra-munin-plugins, for instance.)
CM also has BytesCompacted/BytesTotalInProgress. Backup in deserialize is likely to be (a) the read or write stage being full so deserialize in turn backs up. Anything that sucks up enough CPU could also cause it, I suppose, but other than that (generating lots of CPU load) there is nothing special about compactions wrt deserialize. On Thu, May 20, 2010 at 12:33 PM, Anthony Molinaro <antho...@alumni.caltech.edu> wrote: > Hi, > > In the 0.5.x series there was a COMPACTION-POOL which kept track of > in process, pending and completed compactions. With 0.6.x this seems > to have vanished and instead we only have the CompactionManager PendingTasks > statistic. Is there also a completed tasks somewhere? Is there any > way to determine via nodetool if a compaction or anticompaction is occuring? > I'm trying to figure out the cause of random spikes in the Message > Deserializer > Queue, and wanted to know if there was any correlation with compaction, > but with only PendingTasks, I would have to be sampling continuously to > catch it, as pending is mostly zero. > > Are there other possible causes for a backup in Message Deserializer? > My traffic patterns are pretty constant, I don't see spikes in the > thread pool completed tasks, and often the rate is below the high water > mark for rates. > > Thanks, > > -Anthony > > -- > ------------------------------------------------------------------------ > Anthony Molinaro <antho...@alumni.caltech.edu> > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
