I thought this patch made it into the 1.0 release? I remember it being referenced in one of
the re-rolls.
On Oct 20, 2011, at 9:56 PM, "Jonathan Ellis" <jbellis@gmail.com> wrote:
> That looks to me like it's reporting uncompressed size as the load.
> Should be fixed in the 1.0 branch for 1.0.1.
> (https://issues.apache.org/jira/browse/CASSANDRA-3338)
>
> On Thu, Oct 20, 2011 at 11:53 AM, Dan Hendry <dan.hendry.junk@gmail.com> wrote:
>> I have been playing around with Cassandra 1.0.0 in our test environment it
>> seems pretty sweet so far. I have however come across what appears to be a
>> bug tracking node load. I have enabled compression and levelled compaction
>> on all CFs (scrub + snapshot deletion) and the nodes have been operating
>> normally for a day or two. I started getting concerned when the load as
>> reported by nodetool ring kept increasing (it seems monotonically) despite
>> seeing a compression ratio of ~2.5x (as a side note, I find it strange
>> Cassandra does not provide the compression ratio via jmx or in the logs). I
>> initially thought there might be a bug in cleaning up obsolete SSTables but
>> I then noticed the following discrepancy:
>>
>>
>>
>> Nodetool ring reports:
>>
>> 10.112.27.65 datacenter1 rack1 Up Normal 8.64
>> GB 50.00% 170141183460469231731687303715884105727
>>
>>
>>
>> Yet du . –h reports: only 2.4G in the data directory.
>>
>>
>>
>> After restarting the node, nodetool ring reports a more accurate:
>>
>> 10.112.27.65 datacenter1 rack1 Up Normal 2.35 GB
>> 50.00% 170141183460469231731687303715884105727
>>
>>
>>
>> Again, both compression and levelled compaction have been enabled on all
>> CFs. Is this a known issue or has anybody else observed a similar pattern?
>>
>>
>>
>> Dan Hendry
>>
>> (403) 660-2297
>>
>>
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
|