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 23EC1444A for ; Thu, 7 Jul 2011 11:33:10 +0000 (UTC) Received: (qmail 9577 invoked by uid 500); 7 Jul 2011 11:33:07 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 9393 invoked by uid 500); 7 Jul 2011 11:33:01 -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 9352 invoked by uid 99); 7 Jul 2011 11:33:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jul 2011 11:33:00 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.212.44] (HELO mail-vw0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jul 2011 11:32:51 +0000 Received: by vws12 with SMTP id 12so778225vws.31 for ; Thu, 07 Jul 2011 04:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.161 with SMTP id ij1mr959033vdb.126.1310038350005; Thu, 07 Jul 2011 04:32:30 -0700 (PDT) Sender: scode@scode.org Received: by 10.52.166.136 with HTTP; Thu, 7 Jul 2011 04:32:29 -0700 (PDT) X-Originating-IP: [212.181.83.218] In-Reply-To: References: Date: Thu, 7 Jul 2011 13:32:29 +0200 X-Google-Sender-Auth: ZnMCudgCwZQVzEkzLAt3TPGCU8M Message-ID: Subject: Re: minimum number of machines for RF=3 From: Peter Schuller To: user@cassandra.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org > is this behaviour expected since the RF (for the duration of when 1 node was > taken out) > is higher than the # of nodes? Note that repair is not needed just because a node was off for a while. I am guessing the performance difference was due to the repair. Try running repair at any time and see if you get the same effect. If you are testing with a large data set, repair is probably responsible for evicting data from OS page cache. -- / Peter Schuller