Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <26892443.352911279043891002.JavaMail.jira@thor>
Date: Tue, 13 Jul 2010 13:58:11 -0400 (EDT)
From: "Brandon Williams (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Updated: (CASSANDRA-1275) Log threadpool stats after
 excessive GC
In-Reply-To: <30519079.352541279043870264.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brandon Williams updated CASSANDRA-1275:
----------------------------------------

    Attachment: 1275.txt

> Log threadpool stats after excessive GC
> ---------------------------------------
>
>                 Key: CASSANDRA-1275
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1275
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Brandon Williams
>            Assignee: Brandon Williams
>            Priority: Trivial
>             Fix For: 0.6.4
>
>         Attachments: 1275.txt
>
>
> When GC begins taking longer and longer, it is often a sign that the JVM is going OOM, but it is not clear why.  Often, users swamp the MDP by either writing at CL.ZERO or issuing many read requests while the machine is block on disk IO.  To more easily diagnose this, we should log the threadpool stats when we see a GC take too long.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.