[jira] [Commented] (CASSANDRA-2635) make cache skipping optional

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-2635:
-------------------------------------------

does setting dontneed on a read (our getDirectScanner) actually cause pre-existing pages to be evicted post-read?

in other words, i'm wondering if this should really only change write behavior and leave reads (for compaction) alone.  (non-compaction reads are of course not affected either way.)

also: suggest page_cache_hinting as the option name.

> make cache skipping optional
> ----------------------------
>
>                 Key: CASSANDRA-2635
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2635
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Peter Schuller
>            Assignee: Peter Schuller
>            Priority: Minor
>         Attachments: CASSANDRA-2635-075.txt
>
>
> We've applied this patch locally in order to turn of page skipping; not completely but only for compaction/repair situations where it can be directly detrimental in the sense of causing data to become cold even though your entire data set fits in memory.
> It's better than completely disabling DONTNEED because the cache skipping does make sense and has no relevant (that I can see) detrimental effects in some cases, like when dumping caches.
> The patch is against 0.7.5 right now but if the change is desired I can make a patch for trunk. Also, the name of the configuration option is dubious since saying 'false' does not actually turn it off completely. I wasn't able to figure out a good name that conveyed the functionality in a short brief name however.
> A related concern as discussed in CASSANDRA-1902 is that the cache skipping isn't fsync:ing and so won't work reliably on writes. If the feature is to be retained that's something to fix in a different ticket.
> A question is also whether to retain the default to true or change it to false. I'm kinda leaning to false since it's detrimental in the "easy" cases of little data. In "big" cases with lots of data people will have to think and tweak anyway, so better to put the burden on that end.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira