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
