Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 209.85.215.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F1FD4697-7DD8-4B84-BEC6-2EA25B37E420@morningstar.com>
References: <4ea051fc.0476ec0a.3048.2246@mx.google.com>
 <CALdd-zgkK0p6uhBpBg-7=4Q=+D1a2D_KfUdy0Ya=YBjA+8O7Lg@mail.gmail.com>
 <F1FD4697-7DD8-4B84-BEC6-2EA25B37E420@morningstar.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Fri, 21 Oct 2011 08:37:51 -0500
Message-ID: 
 <CALdd-zjNnVsHRwoudtjWvFLiJFXVfBUb=7S2Fj3KVG2PE12kXQ@mail.gmail.com>
Subject: Re: Cassandra 1.0.0 - Node Load Bug
To: user@cassandra.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

You're right, that is in 1.0.0.  Don't know what the OP is seeing, then.

On Fri, Oct 21, 2011 at 6:32 AM, Jeremiah Jordan
<JEREMIAH.JORDAN@morningstar.com> wrote:
> I thought this patch made it into the 1.0 release? =A0I 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 b=
e a
>>> bug tracking node load. I have enabled compression and levelled compact=
ion
>>> on all CFs (scrub =A0+ snapshot deletion) and the nodes have been opera=
ting
>>> normally for a day or two. I started getting concerned when the load as
>>> reported by nodetool ring kept increasing (it seems monotonically) desp=
ite
>>> 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:
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 10.112.27.65 =A0 =A0datacenter1 rack1 =
=A0 =A0 =A0 Up =A0 =A0 Normal =A08.64
>>> GB =A0 =A0 =A0 =A0 50.00% =A0170141183460469231731687303715884105727
>>>
>>>
>>>
>>> Yet du . =96h reports: only 2.4G in the data directory.
>>>
>>>
>>>
>>> After restarting the node, nodetool ring reports a more accurate:
>>>
>>> 10.112.27.65 =A0 =A0datacenter1 rack1 =A0 =A0 =A0 Up =A0 =A0 Normal =A0=
2.35 GB
>>> 50.00% =A0170141183460469231731687303715884105727
>>>
>>>
>>>
>>> Again, both compression and levelled compaction have been enabled on al=
l
>>> CFs. Is this a known issue or has anybody else observed a similar patte=
rn?
>>>
>>>
>>>
>>> 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
>


--=20
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com