Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 1 Dec 2014 16:15:12 +0000 (UTC)
From: =?utf-8?Q?Jimmy_M=C3=A5rdell_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12755180.1415917826000.49395.1417450512718@Atlassian.JIRA>
In-Reply-To: <JIRA.12755180.1415917826000@Atlassian.JIRA>
References: <JIRA.12755180.1415917826000@Atlassian.JIRA>
 <JIRA.12755180.1415917826355@arcas>
Subject: [jira] [Commented] (CASSANDRA-8312) Use live sstables in snapshot
 repair if possible
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-8312?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14229956#comment-14229956 ]=20

Jimmy M=C3=A5rdell commented on CASSANDRA-8312:
------------------------------------------

Ping on this.

I'm okay if you think this patch is unnecessary due to CASSANDRA-7024, but =
I'd still be very happy with some feedback on if this approach is correct. =
[~krummas]?

> Use live sstables in snapshot repair if possible
> ------------------------------------------------
>
>                 Key: CASSANDRA-8312
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8312
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jimmy M=C3=A5rdell
>            Assignee: Jimmy M=C3=A5rdell
>            Priority: Minor
>         Attachments: cassandra-2.0-8312-1.txt
>
>
> Snapshot repair can be very much slower than parallel repairs because of =
the overhead of opening the SSTables in the snapshot. This is particular tr=
ue when using LCS, as you typically have many smaller SSTables then.
> I compared parallel and sequential repair on a small range on one of our =
clusters (2*3 replicas). With parallel repair, this took 22 seconds. With s=
equential repair (default in 2.0), the same range took 330 seconds! This is=
 an overhead of 330-22*6 =3D 198 seconds, just opening SSTables (there were=
 1000+ sstables). Also, opening 1000 sstables for many smaller rangers sure=
ly causes lots of memory churning.
> The idea would be to list the sstables in the snapshot, but use the corre=
sponding sstables in the live set if it's still available. For almost all s=
stables, the original one should still exist.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)