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

Benedict edited comment on CASSANDRA-8860 at 2/27/15 2:10 AM:
--------------------------------------------------------------

One way to do this might be, for each reader:

* find its overlaps;
** for each overlap, find _its_ set of overlaps, but discard these unless 
they're both larger than the one we've most recently kept, _and_ the estimated 
win is sufficient
* remove all of the (first layer of) overlaps from the readers we visit, and 
continue with the next remaining reader

This gives us linear space complexity, but possibly still quadratic time 
complexity in the worst case, which is trickier to improve.


was (Author: benedict):
One way to do this might be, for each table:

* find the overlaps;
** for each overlap, find _its_ set of overlaps, but keep only the largest 
where the estimated win is sufficient
* remove all of the (first layer of) overlaps from the files we visit

This gives us linear space complexity, but possibly still quadratic time 
complexity in the worst case, which is trickier to improve.

> 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: Marcus Eriksson
>             Fix For: 2.1.4
>
>         Attachments: cassandra-env.sh, cassandra.yaml, jmap.txt, jstack.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)

Reply via email to