Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 59614 invoked from network); 14 Apr 2010 06:00:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Apr 2010 06:00:43 -0000 Received: (qmail 25475 invoked by uid 500); 14 Apr 2010 06:00:42 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 25461 invoked by uid 500); 14 Apr 2010 06:00:41 -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 25311 invoked by uid 99); 14 Apr 2010 06:00:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Apr 2010 06:00:41 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of scode@spotify.com designates 209.85.218.222 as permitted sender) Received: from [209.85.218.222] (HELO mail-bw0-f222.google.com) (209.85.218.222) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Apr 2010 06:00:35 +0000 Received: by bwz22 with SMTP id 22so7050674bwz.25 for ; Tue, 13 Apr 2010 23:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.152.4 with HTTP; Tue, 13 Apr 2010 23:00:13 -0700 (PDT) In-Reply-To: <33FDEB0CE2F65F41A4CF8769247BB3668DC5CC6334@EXVMBX016-3.exch016.msoutlookonline.net> References: <61401.54585.qm@web111713.mail.gq1.yahoo.com> <33FDEB0CE2F65F41A4CF8769247BB3668DC5CC6334@EXVMBX016-3.exch016.msoutlookonline.net> Date: Wed, 14 Apr 2010 08:00:13 +0200 Received: by 10.102.216.24 with SMTP id o24mr3811150mug.67.1271224813392; Tue, 13 Apr 2010 23:00:13 -0700 (PDT) Message-ID: Subject: Re: GC options From: =?UTF-8?Q?Peter_Sch=C3=BCller?= To: user@cassandra.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > I'm working on getting our latency as consistent as possible, and the gc = likes to kick off 60+ms periods of unavailability for a node, which for my = application leads to a reasonable number of timed out requests. Outside of = the gc event, we get good responses. > > I'm happy with reduced throughput for shorter pauses, so I'm going to do = the standard jvm gc tuning guide[0] for short pauses, curious if anyone els= e has gone down this path and gotten gc pauses consistent and low or if wha= t's in bin/cassandra.in.sh is basically the best I should expect. (Anyone t= ried jrockit?) If your situation is such that you are willing to use the unreleased JDK 1.7 and G1GC (still being marked as experimental and may still be a stability concern and since we are talking about storing data that probably means conservatism is called for) you can try that. It offers some more direct control over the target GC pause times, although does not provide guarantees. A potential starting point of VM options may be: -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=3D10 -XX:GCPauseIntervalMillis=3D15 And maybe: -XX:G1ConfidencePercent=3D100 And maybe (not sure of current status but there used to be a known bug when enabled): -XX:+G1ParallelRSetUpdatingEnabled -XX:+G1ParallelRSetScanningEnabled --=20 / Peter Schuller aka scode