[
https://issues.apache.org/jira/browse/CASSANDRA-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694202#comment-13694202
]
Jeremiah Jordan commented on CASSANDRA-5661:
--------------------------------------------
Screen shots attached to show the issue.
Histogram.png show my histogram. Over 2 GB is being retained by CRAR objects
on a node with only 80 GB of data, most of that in LCS CF's with 20 MB sstable
size, and some ine LCS CF's with 10 MB sstable size.
!Histogram.png!
Here is the dominator tree for that same heap dump.
!DominatorTree.png!
The problem is that most of those sstables have 1 MB or more of CRAR buffers
sitting there waiting to be used. If we do a timer with an absolute cap, even
better, but we need some kind of cap.
The compression overhead itself isn't really an issue, the issue is the cached
CRAR objects/buffers.
> Discard pooled readers for cold data
> ------------------------------------
>
> Key: CASSANDRA-5661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5661
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.1
> Reporter: Jonathan Ellis
> Assignee: Pavel Yaskevich
> Fix For: 1.2.7
>
> Attachments: DominatorTree.png, Histogram.png
>
>
> Reader pooling was introduced in CASSANDRA-4942 but pooled
> RandomAccessReaders are never cleaned up until the SSTableReader is closed.
> So memory use is "the worst case simultaneous RAR we had open for this file,
> forever."
> We should introduce a global limit on how much memory to use for RAR, and
> evict old ones.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
