cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Yang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-8860) Too many java.util.HashMap$Entry objects in heap
Date Fri, 27 Feb 2015 11:05:05 GMT

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

Phil Yang edited comment on CASSANDRA-8860 at 2/27/15 11:04 AM:
----------------------------------------------------------------

I tested my patch in my node on 2.1.3. The patch works to me that it won't exhaust the heap
although the gc pressure is high.

Furthermore, if my understanding is not wrong, I think there is an improvement on this O(N^2)
algorithm:
{noformat}
If createOverlapChain(a, overlapMap) return {a,b,c}, createOverlapChain(b, overlapMap) must
also return {a,b,c},  because "overlapping" is a bidirectional relationship. So if we have
already get {a,b,c} by SStableReader a, we needn't check b and c at all.
{noformat}
So this algorithm is O(N) both in time and space.


was (Author: yangzhe1991):
I tested my patch in my node on 2.1.3. The patch works to me that it won't exhaust the heap
although the gc pressure is high.

Furthermore, if my understanding is not wrong, I think there is an improvement on this O(N^2)
algorithm:
If createOverlapChain(a, overlapMap) return {a,b,c}, createOverlapChain(b, overlapMap) must
also return {a,b,c},  because "overlapping" is a bidirectional relationship. So if we have
already get {a,b,c} by SStableReader a, we needn't check b and c at all.
So this algorithm is O(N) both in time and space.

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

Mime
View raw message