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 2015/03/01 04:24:05 UTC

[jira] [Comment Edited] (CASSANDRA-8860) Too many java.util.HashMap$Entry objects in heap

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

Jonathan Ellis edited comment on CASSANDRA-8860 at 3/1/15 3:23 AM:
-------------------------------------------------------------------

That's a lot of complexity for something whose benefit I'm unclear on (I'm talking about the "ignore cold sstables" feature).

To the best of my knowledge, CASSANDRA-8635 has never been observed as a problem in the wild.  I'd be in favor of reverting it and documenting "don't enable cold sstable elision if you do a lot of overwrites."


was (Author: jbellis):
That's a lot of complexity for something whose benefit I'm unclear on (I'm talking about the "ignore cold sstables feature").

To the best of my knowledge, CASSANDRA-8635 has never been observed as a problem in the wild.  I'd be in favor of reverting it and documenting "don't enable cold sstable elision if you do a lot of overwrites."

> Too many java.util.HashMap$Entry objects in heap
> ------------------------------------------------
>
>                 Key: CASSANDRA-8860
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8860
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 2.1.3, jdk 1.7u51
>            Reporter: Phil Yang
>            Assignee: Phil Yang
>             Fix For: 2.1.4
>
>         Attachments: 8860-v2.txt, 8860.txt, cassandra-env.sh, cassandra.yaml, jmap.txt, jstack.txt, jstat-afterv1.txt, jstat-afterv2.txt, jstat-before.txt
>
>
> While I upgrading my cluster to 2.1.3, I find some nodes (not all) may have GC issue after the node restarting successfully. Old gen grows very fast and most of the space can not be recycled after setting its status to normal immediately. The qps of both reading and writing are very low and there is no heavy compaction.
> Jmap result seems strange that there are too many java.util.HashMap$Entry objects in heap, where in my experience the "[B" is usually the No1.
> If I downgrade it to 2.1.1, this issue will not appear.
> I uploaded conf files and jstack/jmap outputs. I'll upload heap dump if someone need it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)