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" <jbel...@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.j...@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
