You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2010/07/13 21:38:50 UTC

[jira] Commented: (CASSANDRA-1275) Log threadpool stats after excessive GC

    [ https://issues.apache.org/jira/browse/CASSANDRA-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887947#action_12887947 ] 

Jonathan Ellis commented on CASSANDRA-1275:
-------------------------------------------

let's drop the redundant

+                logger.info("Logging threadpool stats due to excessive GC");

and s/for loop w/ only the bool test / while loop

+1 otherwise

(and add to CHANGES pls)

> 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.