cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Compaction JMX Stats?
Date Thu, 20 May 2010 21:11:23 GMT
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, 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
<> 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                           <>

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support

View raw message