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

Pavel Yaskevich commented on CASSANDRA-5661:
--------------------------------------------

bq. 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.

1MB actually means that it's around 12-14 caches reads which is not even half 
of default concurrency limit, we can start with expiring for 1.2.7 as it 
doesn't require adding options (and maybe disable caching with LCS), then for 
2.0 we can add cap limit per CF or even global into yaml.

bq. The compression overhead itself isn't really an issue, the issue is the 
cached CRAR objects/buffers.

It is for such a small files because it's not just buffers but also compression 
metadata per SSTable although you can't see it in histogram/tree as it was 
moved off heap, I guess it's an artifact of LCS that we can't do anything about.

This all got me wondering what is BF space overhead LCS vs. STCS, can you 
please check?
                
> 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

Reply via email to