cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4894) log number of combined/merged rows during a compaction
Date Wed, 19 Dec 2012 10:33:12 GMT


Sylvain Lebresne commented on CASSANDRA-4894:

I tend to think that the log is more suited to human readable information than machine parseable
ones (don't get me wrong, I'm sure lots of people do have script to manipulate the log, I'm
just not sure it's the idea tool for that, especially considering we haven't really concerned
ourselves with machine parseability so far).

I do agree though that compaction stats is probably important enough that you may want to
monitor that closely and I would in fact be in favor of saving compaction stats in a System
table (much like we plan to save repair stats at some point). That would be imo the good place
to be machine friendly.

That being said, if you guys prefer the shorter format, and provided that at the time of this
ticket the log will be the only place where that information will be available, I'm fine with
that. But I do anticipate people asking what those numbers means on irc quite a few time,
and I do think having things self-descriptive is a better user experience than having to go
find documentation somewhere on the net, even if said doc exists. I could be wrong though
and again, not a big deal in any case.
> log number of combined/merged rows during a compaction
> ------------------------------------------------------
>                 Key: CASSANDRA-4894
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Matthew F. Dennis
>            Assignee: Yuki Morishita
>            Priority: Minor
>             Fix For: 1.2.1
>         Attachments: 4894-1.2.txt
> we already log some details about compactions but it would be useful to know how many
rows were merged (resulting in "useful" work) and how many were unique (representing "wasted
> the simple approach requires two additional counters (one for unique rows, one for merged
rows).  As the merge join is progressing if two or more rows are combined, tick the joined
counter.  If a row is simply copied tick the unique counter.
> a more complete solution would be to keep a separate count for each number of merges.
 This would require number_of_files_being_merged counters.  If no rows were merged, tick counters[0],
if two rows were merged tick counters[1] and so on 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message