Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E762610078 for ; Wed, 5 Feb 2014 19:20:41 +0000 (UTC) Received: (qmail 36474 invoked by uid 500); 5 Feb 2014 19:20:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 36444 invoked by uid 500); 5 Feb 2014 19:20:37 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 36436 invoked by uid 99); 5 Feb 2014 19:20:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Feb 2014 19:20:37 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kwright@nanigans.com designates 216.82.254.97 as permitted sender) Received: from [216.82.254.97] (HELO mail1.bemta7.messagelabs.com) (216.82.254.97) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Feb 2014 19:20:33 +0000 Received: from [216.82.253.99:28812] by server-1.bemta-7.messagelabs.com id D7/21-21296-9EE82F25; Wed, 05 Feb 2014 19:20:09 +0000 X-Env-Sender: kwright@nanigans.com X-Msg-Ref: server-16.tower-160.messagelabs.com!1391628008!7807463!1 X-Originating-IP: [216.166.12.98] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2432 invoked from network); 5 Feb 2014 19:20:09 -0000 Received: from out001.collaborationhost.net (HELO out001.collaborationhost.net) (216.166.12.98) by server-16.tower-160.messagelabs.com with RC4-SHA encrypted SMTP; 5 Feb 2014 19:20:09 -0000 Received: from AUSP01VMBX28.collaborationhost.net ([192.168.20.73]) by AUSP01MHUB07.collaborationhost.net ([10.2.8.242]) with mapi; Wed, 5 Feb 2014 13:19:09 -0600 From: Keith Wright To: "user@cassandra.apache.org" CC: Don Jackson , Dave Carroll Date: Wed, 5 Feb 2014 13:18:02 -0600 Subject: Re: Move to smaller nodes Thread-Topic: Move to smaller nodes Thread-Index: Ac8ipyThTWuzAuM7RRe3+cVbfybISA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF17F7B71F72Ekwrightnaniganscom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CF17F7B71F72Ekwrightnaniganscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Rob, thanks for the response! Interestingly if we run a repair we don= =92t see the bootstrap issue so I am considering doing the empty node repai= r methodology. Its just that it usually takes a week for that to work. As= I see it, we could try the following to fix the bootstrap issue: * Update our JRE, we are using 1.7.0_17 and I believe we=92re up to 1.7.= 0_54 * GC tuning as it does appear that we=92re suffering from GC issues. We= could just allocate more eden space and then revert after the bootstrap su= cceeds * As I mentioned, don=92t load data via bootstrap but instead use repair= . With bootstrap disabled in Vnodes, will the node still assign itself tok= ens? Thanks From: Robert Coli > Reply-To: "user@cassandra.apache.org" > Date: Wednesday, February 5, 2014 at 2:10 PM To: "user@cassandra.apache.org" > Cc: Don Jackson >, Dave= Carroll > Subject: Re: Move to smaller nodes http://www.palominodb.com/blog/2012/09/25/bulk-loading-options-cassandra --_000_CF17F7B71F72Ekwrightnaniganscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Rob, thanks for the response!=  Interestingly if we run a repair we don=92t see the bootstrap issue = so I am considering doing the empty node repair methodology.  Its just= that it usually takes a week for that to work.  As I see it, we could= try the following to fix the bootstrap issue:
  • Update our JRE,= we are using 1.7.0_17 and I believe we=92re up to 1.7.0_54
  • GC tuni= ng as it does appear that we=92re suffering from GC issues.  We could = just allocate more eden space and then revert after the bootstrap succeeds<= /li>
  • As I mentioned, don=92t load data via bootstrap but instead use rep= air.  With bootstrap disabled in Vnodes, will the node still assign it= self tokens?
Thanks

From: Robert Coli <rcoli@eventbrite.com>
Reply-To: "user= @cassandra.apache.org" <user@cassandra.apache.org>
Date: Wednesday, February 5, 2014 at 2:10 PM
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Cc: Don Jackson <djackson@nanigans.com>, Dave Carroll <dcarroll@nanigans.com>
Subject: Re: Move to smaller nodes

<= a href=3D"http://www.palominodb.com/blog/2012/09/25/bulk-loading-options-ca= ssandra" style=3D"font-family: Calibri; font-size: medium; font-style: norm= al; font-variant: normal; font-weight: normal; letter-spacing: normal; line= -height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t= ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk= it-text-stroke-width: 0px;">http://www.palominodb.com/blog/2012/09/25/bulk-= loading-options-cassandra --_000_CF17F7B71F72Ekwrightnaniganscom_--