[
https://issues.apache.org/jira/browse/CASSANDRA-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013632#comment-13013632
]
Peter Schuller commented on CASSANDRA-1902:
-------------------------------------------
(isPageCaheMigrationEnabled is misspelled.)
I tested some on 2.6.32 (it's what I have easily available on running physical
h/w). I used stress.py as per the earlier benchmarks in this ticket, but after
initial population I just used 'nodetool compact' to trigger compaction. (I
tested with standard I/O because I happened to make the changes to the BSF
(below), and I also realized I'm not sure where the pre-pop happens for the
mmap case. Will have to revisit.)
I added some logging and a sleep to
BufferedSegmentedFile.tryPreserveFilePageCache() (I'll attach the patch to that
file only, it's only for testing purposes). By doing 'sync ; echo 1 >
/proc/sys/vm/drop_caches' I artificially triggered the newly written file not
being in page cache at all (essentially simulating compacting a sufficiently
large sstable that <10% (or such) fits in ram).
A compaction after letting:
python contrib/py_stress/stress.py -S 3000 -n 100000 -o read
run for a while (~ 5 thousand progress), with the above drop cache /
compaction, gave:
WARN 22:06:56,723 about to preserve, please drop caches
WARN 22:07:06,723 begin preserve
WARN 22:07:34,299 end preserve
So firstly, this shows WILLNEED being blocking (I guess I should have looked
closer, or it's different due to the .32 kernel).
During this time I observed "iostat -x -k 1". There was an initial flurry of
I/O with queue depth > 100, but it then settled for a queue depth of around 5-6
or so for the remainder of the period. Here is a fairly typical second (no
pretty graphs I'm afraid):
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz
avgqu-sz await svctm %util
sda 6.00 0.00 152.00 0.00 61716.00 0.00 812.05
5.05 33.13 6.16 93.60
> 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, CASSANDRA-1902-v6.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
