[
https://issues.apache.org/jira/browse/CASSANDRA-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494441#comment-13494441
]
Pavel Yaskevich commented on CASSANDRA-4937:
--------------------------------------------
bq. Still don't like the global objectCache code. SSTR queue (no Map) would be
better. Or, what about SSTR Threadlocal?
The reason why it's done via queues associated with filenames is that we want
to get rid of CRAR instances as soon as we done with individual SSTables and I
don't want to involve SSTR there more then just cleaning queues upon
termination.
bq. Isn't the right fix then to only drop the recently-read blocks during
sequential i/o?
We can't because it would require (e.g. compaction) to know of how something is
using files, it could remove cache from somebody's fit anyway and we would use
too many system calls if we do that.
> CRAR improvements (object cache + CompressionMetadata chunk offset storage
> moved off-heap).
> -------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-4937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4937
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.6
> Reporter: Pavel Yaskevich
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.1.7
>
> Attachments: CASSANDRA-4937.patch
>
>
> After good amount of testing on one of the clusters it was found that in
> order to improve read latency we need to minimize allocation rate that
> compression involves, that minimizes GC (as well as heap usage) and
> substantially decreases latency on read heavy workloads.
> I have also discovered that RAR skip cache harms performance in situation
> when reads are done in parallel with compaction working with relatively big
> SSTable files (few GB and more). The attached patch removes possibility to
> skip cache from compressed files (I can also add changes to RAR to remove
> skip cache functionality as a separate patch).
--
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
