Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sun, 1 Mar 2015 10:41:05 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12777272.1424807227000.45589.1425206465226@Atlassian.JIRA>
In-Reply-To: <JIRA.12777272.1424807227000@Atlassian.JIRA>
References: <JIRA.12777272.1424807227000@Atlassian.JIRA>
 <JIRA.12777272.1424807227751@arcas>
Subject: [jira] [Commented] (CASSANDRA-8860) Too many
 java.util.HashMap$Entry objects in heap
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Benedict commented on CASSANDRA-8860:
-------------------------------------

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

Quite possibly. I've no idea how much use this is. The ability to select overlaps efficiently I assumed would be of wider applicability, but it looks like we don't use it anywhere else. However we might in future? The compaction exercise Marcus runs to intro devs to C* utilises it, so not sure if that is just a toy problem or of wider potential.

bq. Just like the comment on this function says: "if we have 3 sstables, a, b, c where a overlaps with b, but not c and b overlaps with c, all sstables would be returned."

Good point. With that realisation, the code I knocked out on the plane is trivially made guaranteed O(n lg n) (for sorting, O(n) for the remainder of the work), with O(n) space complexity. It is untested, and could be refactored not to use an Iterable (which might be less code complexity), but I upload it [here|https://github.com/belliottsmith/cassandra/tree/8860-alt] for you and Marcus to decide what to do with.

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