Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 2840 invoked from network); 9 Oct 2010 08:53:50 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Oct 2010 08:53:50 -0000 Received: (qmail 69947 invoked by uid 500); 9 Oct 2010 08:53:48 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 69849 invoked by uid 500); 9 Oct 2010 08:53:46 -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 69837 invoked by uid 99); 9 Oct 2010 08:53:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Oct 2010 08:53:45 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.160.172] (HELO mail-gy0-f172.google.com) (209.85.160.172) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Oct 2010 08:53:35 +0000 Received: by gyb11 with SMTP id 11so547767gyb.31 for ; Sat, 09 Oct 2010 01:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.87.4 with SMTP id p4mr4249169ybl.397.1286614394179; Sat, 09 Oct 2010 01:53:14 -0700 (PDT) Sender: scode@scode.org Received: by 10.150.60.11 with HTTP; Sat, 9 Oct 2010 01:53:14 -0700 (PDT) X-Originating-IP: [213.114.156.79] In-Reply-To: References: <4C938CF3.2060907@digg.com> Date: Sat, 9 Oct 2010 10:53:14 +0200 X-Google-Sender-Auth: iRisuf0c2qk_PU-q78vGwFOtYL4 Message-ID: Subject: Re: Dazed and confused with Cassandra on EC2 ... From: Peter Schuller To: user@cassandra.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org > The main reason to set Xms=3DXmx is so mlockall can tag the entire heap > as "don't swap this out" on startup. =C2=A0Secondarily whenever the heap > resizes upwards the JVM does a stop-the-world gc, but no, not really a > big deal when your uptime is in days or weeks. I'm not sure where this is coming from, assuming you mean a *full* stw GC. I cannot remember ever observing this in "all my hears of heap growth ;)", and I don't see why it would be the case. Heap *shrinkage* on the other hand is another matter and for both CMS and G1, shrinkage never happens except on Full GC, unfortunately. I'm hoping G1 will eventually improve here since its compacting design should fundamentally make it feasible to implement efficiently. Disregarding the mlockall issue which is pretty specific to Cassandra, the typical reason, as I have understood it, for setting Xms=3DXmx on machine dedicatedly running some particular JVM is that if you have to reserve Xmx amount of memory anyway, and perhaps even expect that to be reached, it is generally more efficiency to just let the JVM use it all from the start - due to the usual effect of GC being more efficient with larger heap sizes and in order to avoid bad policy decisions of the GC causing excessive GC activity rather than just growing the heap which you're fine with anyway. --=20 / Peter Schuller