Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 38442 invoked from network); 8 Mar 2011 12:25:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Mar 2011 12:25:41 -0000 Received: (qmail 41965 invoked by uid 500); 8 Mar 2011 12:25:39 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 41941 invoked by uid 500); 8 Mar 2011 12:25:39 -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 41933 invoked by uid 99); 8 Mar 2011 12:25:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Mar 2011 12:25:39 +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 [74.125.83.43] (HELO mail-gw0-f43.google.com) (74.125.83.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Mar 2011 12:25:30 +0000 Received: by gwb11 with SMTP id 11so3474729gwb.30 for ; Tue, 08 Mar 2011 04:25:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.151.32.1 with SMTP id k1mr4157414ybj.385.1299587105057; Tue, 08 Mar 2011 04:25:05 -0800 (PST) Sender: scode@scode.org Received: by 10.151.79.11 with HTTP; Tue, 8 Mar 2011 04:25:04 -0800 (PST) X-Originating-IP: [213.114.148.106] In-Reply-To: References: <4D7553DD.1080702@yellowseo.com> Date: Tue, 8 Mar 2011 13:25:04 +0100 X-Google-Sender-Auth: NXdw1w6rdWRda3RRtT0a7gV7lIM Message-ID: Subject: Re: Nodes frozen in GC From: Peter Schuller To: user@cassandra.apache.org Cc: Paul Pak Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org > (1) I cannot stress this one enough: Run with -XX:+PrintGC > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps and collect the output. Actually, I wonder if it's worth someone getting this enabled by default, with the obvious problems associated with getting the log output placed appropriately and rotated. But it really seems to me like almost every single case of people having problems on the ML:s would be helped by having instant access to the GC log to rule things out very quickly and expediently. I'm not aware of a good simple way to do so though, since the JVM emits it on stdout (not even stderr) by default, or else to a fixed file and supports no rotation. Making the file a fifo is possible, but then one has to have someone reading that file and then that thing must be monitored, and you introduce the possibility of the log reader causing JVM hiccups, etc.... does anyone have a good practice for running production code with GC logging in a way that doesn't interfer with the normal user who's not actively using it/caring about it? A related potential mode of backfire is that it might cause blocking writes to stdout on systems bottlenecking on disk I/O. Maybe it's just not realistic. -- / Peter Schuller