[
https://issues.apache.org/jira/browse/CASSANDRA-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190827#comment-14190827
]
Matt Stump commented on CASSANDRA-8160:
---------------------------------------
I have something semi-functional against trunk, but it's going to be another
week or two before I can touch it again. I realized afterwards what I should
really be targeting is 2.1 and 2.0 because 3.0 is going to blow up all this
code.
The constructor logic for sstable reader is a bit of a mess, so it's difficult
to find a clean entry point to do this that doesn't include lots of code
duplication, and yet distinguish between opening an sstable on boot vs an
sstable after write.
That being said I was at a retailer, and the newly written sstables weren't
being moved up into the buffer cache as aggressively as one would hope. After
reading the sstables out to /dev/null, forcing the population of the buffer
cache, the percentage of queries over SLA went from 15% down to <1%, for a node
that had a dataset of 5GB and 256GB of memory.
> CF level option to call posix_fadvise for sstables on creation and startup
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-8160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8160
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Matt Stump
> Assignee: Branimir Lambov
> Priority: Minor
> Fix For: 2.1.2
>
>
> We should have a CF level configuration with will result in posix_fadvise
> being called for sstables for that CF. It should be called on node startup
> and for new sstables. This should be configurable per CF to allow for some
> CFs to be prioritized above others. Not sure if we should use
> POSIX_FADV_SEQUENTIAL or POSIX_FADV_WILLNEED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
