[
https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012793#comment-13012793
]
Pavel Yaskevich commented on CASSANDRA-1902:
--------------------------------------------
bq. With respect to avoiding waiting on GC: the munmap() is still in finalize()
we we're still waiting on GC, right? Just not on every possible ByteBuffer
(instead only on the MappedFileSegment itself).
This is correct but on other hand we can unmap segment only when we don't need
a reader, I can do an explicite method for it but my tests show that unmap in
finalize if pretty useful.
bq. BufferedSegmentedFile.tryPreserveFilePageCache() is doing a
tryPreserveCacheRegion() for every page considered hot. The first thing to be
aware of then is that this will translate into a posix_fadvise() syscall for
every page, even when all or almost all pages are in fact in memory. This may
be acceptable, but keep in mind that use-cases where all or almost all pages
are in cache, are likely to be the ones CPU-bound rather than disk bound.
Documentation for posix_fadvice/madvice calls suggests to do more frequent
little requests instead of big requests - kernel in the high possibility going
to ignore an advice on the big region.
bq. fadvising entire regions at once instead of once per page might improve
that, but I still think the better solution is to just not DONTNEED hot data to
begin with (subject to potential limitations to avoid too frequent DONTNEEDs).
We can't stop using DONTNEED while writing compacted file because it will suck
pages from sstables which are currently in use. And we do WILLNEED's only when
we have SSTableReader for a compacted file ready - right before old sstables
going to be replaced with new ones so this is not going to make a big
performance impact on the reads. Note that WILLNEED is non-blocking call.
bq. Minor nit: Seemingly truncated doc string for SegmentedFile.complete().
Yes, I will fix that, thanks!
bq. Minor suggestion: Should isRangeInCache() be renamed to wasRangeInCache()
to reflect the fact that it does not represent current status? It is not an
implementation detail because if it did reflect current reality, the caller
would be incorrect (the test on a per-column basis would constantly give false
positives as being in cache due to (1) the column just having been serialized,
which would be easily fixable, but also because (2) previous columns on the
same page, which is more difficult to fix than moving a line of code).
Sounds reasonable to me, I will rename a method.
> Migrate cached pages during compaction
> ---------------------------------------
>
> Key: CASSANDRA-1902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1902
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.1
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Fix For: 0.7.5, 0.8
>
> Attachments:
> 0001-CASSANDRA-1902-cache-migration-impl-with-config-option.txt,
> 1902-formatted.txt, 1902-per-column-migration-rebase2.txt,
> 1902-per-column-migration.txt, CASSANDRA-1902-v3.patch,
> CASSANDRA-1902-v4.patch, CASSANDRA-1902-v5.patch
>
> Original Estimate: 32h
> Time Spent: 56h
> Remaining Estimate: 0h
>
> Post CASSANDRA-1470 there is an opportunity to migrate cached pages from a
> pre-compacted CF during the compaction process. This is now important since
> CASSANDRA-1470 caches effectively nothing.
> For example an active CF being compacted hurts reads since nothing is cached
> in the new SSTable.
> The purpose of this ticket then is to make sure SOME data is cached from
> active CFs. This can be done my monitoring which Old SSTables are in the page
> cache and caching active rows in the New SStable.
> A simpler yet similar approach is described here:
> http://insights.oetiker.ch/linux/fadvise/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
