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 watanabe.maki@gmail.com
 designates 209.85.214.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4D6B44DB-F9E0-4AEB-887C-2D0BF3C25DFF@chors.de>
References: <73FEEF67-8BD2-4D5A-8D0C-6C6CC6FB14F2@chors.de>
	<CAOT3TWoYAqk4thdvM2fzKZ-G7Q6K=c2ah46hhKMLKBdwuu8kjA@mail.gmail.com>
	<4D6B44DB-F9E0-4AEB-887C-2D0BF3C25DFF@chors.de>
Date: Wed, 18 Jan 2012 10:19:51 +0900
Message-ID: 
 <CALqbeQavzQjDsfLuLHYB_26MhowdGh1B4N18NC_frMZe0=NOsQ@mail.gmail.com>
Subject: Re: Unbalanced cluster with RandomPartitioner
From: Maki Watanabe <watanabe.maki@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Are there any significant difference of number of sstables on each nodes?

2012/1/18 Marcel Steinbach <marcel.steinbach@chors.de>:
> We are running regular repairs, so I don't think that's the problem.
> And the data dir sizes match=A0approx.=A0the load from the nodetool.
> Thanks for the advise, though.
>
> Our keys are digits only, and all contain a few zeros at the same
> offsets.=A0I'm not that familiar with the md5 algorithm, but I doubt that=
 it
> would generate 'hotspots' for those kind of keys, right?
>
> On 17.01.2012, at 17:34, Mohit Anchlia wrote:
>
> Have you tried running repair first on each node? Also, verify using
> df -h on the data dirs
>
> On Tue, Jan 17, 2012 at 7:34 AM, Marcel Steinbach
> <marcel.steinbach@chors.de> wrote:
>
> Hi,
>
>
> we're using RP and have each node assigned the same amount of the token
> space. The cluster looks like that:
>
>
> Address =A0 =A0 =A0 =A0 Status State =A0 Load =A0 =A0 =A0 =A0 =A0 =A0Owns=
 =A0 =A0Token
>
>
> 205648943402372032879374446248852460236
>
> 1 =A0 =A0 =A0 Up =A0 =A0 Normal =A0310.83 GB =A0 =A0 =A0 12.50%
> =A056775407874461455114148055497453867724
>
> 2 =A0 =A0 =A0 Up =A0 =A0 Normal =A0470.24 GB =A0 =A0 =A0 12.50%
> =A078043055807020109080608968461939380940
>
> 3 =A0 =A0 =A0 Up =A0 =A0 Normal =A0271.57 GB =A0 =A0 =A0 12.50%
> =A099310703739578763047069881426424894156
>
> 4 =A0 =A0 =A0 Up =A0 =A0 Normal =A0282.61 GB =A0 =A0 =A0 12.50%
> =A0120578351672137417013530794390910407372
>
> 5 =A0 =A0 =A0 Up =A0 =A0 Normal =A0248.76 GB =A0 =A0 =A0 12.50%
> =A0141845999604696070979991707355395920588
>
> 6 =A0 =A0 =A0 Up =A0 =A0 Normal =A0164.12 GB =A0 =A0 =A0 12.50%
> =A0163113647537254724946452620319881433804
>
> 7 =A0 =A0 =A0 Up =A0 =A0 Normal =A076.23 GB =A0 =A0 =A0 =A012.50%
> =A0184381295469813378912913533284366947020
>
> 8 =A0 =A0 =A0 Up =A0 =A0 Normal =A019.79 GB =A0 =A0 =A0 =A012.50%
> =A0205648943402372032879374446248852460236
>
>
> I was under the impression, the RP would distribute the load more evenly.
>
> Our row sizes are 0,5-1 KB, hence, we don't store huge rows on a single
> node. Should we just move the nodes so that the load is more even
> distributed, or is there something off that needs to be fixed first?
>
>
> Thanks
>
> Marcel
>
> <hr style=3D"border-color:blue">
>
> <p>chors GmbH
>
> <br><hr style=3D"border-color:blue">
>
> <p>specialists in digital and direct marketing solutions<br>
>
> Haid-und-Neu-Stra=DFe 7<br>
>
> 76131 Karlsruhe, Germany<br>
>
> www.chors.com</p>
>
> <p>Managing Directors: Dr. Volker Hatz, Markus Plattner<br>Amtsgericht
> Montabaur, HRB 15029</p>
>
> <p style=3D"font-size:9px">This e-mail is for the intended recipient only=
 and
> may contain confidential or privileged information. If you have received
> this e-mail by mistake, please contact us immediately and completely dele=
te
> it (and any attachments) and do not forward it or inform any other person=
 of
> its contents. If you send us messages by e-mail, we take this as your
> authorization to correspond with you by e-mail. E-mail transmission canno=
t
> be guaranteed to be secure or error-free as information could be
> intercepted, amended, corrupted, lost, destroyed, arrive late or incomple=
te,
> or contain viruses. Neither chors GmbH nor the sender accept liability fo=
r
> any errors or omissions in the content of this message which arise as a
> result of its e-mail transmission. Please note that all e-mail
> communications to and from chors GmbH may be monitored.</p>
>
>


--=20
w3m