[
https://issues.apache.org/jira/browse/CASSANDRA-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14342007#comment-14342007
]
Phil Yang commented on CASSANDRA-8860:
--------------------------------------
{quote}
This is unfortunately not true. a may overlap b and c, but b may only overlap
a, and not c, for instance.
{quote}
Your case is just like this, right?
{noformat}
b -----
a -----
c ------
{noformat}
However, in the code of createOverlapChain, all the overlapping SSTables with b
will be pushed into the queue(for this case is a). When a is popped, all the
overlapping SSTables with a(for this case is c) will also be pushed, until
there is no more SSTables that overlap any of SSTables in overlapChain(\{a,b,c}
for this case). 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."
So in graph theory, this function input "Map<SSTableReader, Set<SSTableReader>>
m" as an undirected graph and "SSTableReader s" as a node of this graph, will
return the connected component which contains this node. If this connected
component is \{a,b,c}, input a, b or c will return the same connected component.
> 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)
