[
https://issues.apache.org/jira/browse/CASSANDRA-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984675#comment-13984675
]
Joshua McKenzie commented on CASSANDRA-6890:
--------------------------------------------
I did some further performance testing for CASSANDRA-7001 to make sure there
weren't any performance regressions and mmap'ed index file I/O performance on
linux looks to have a decidedly different profile than on Windows.
|Linux Mmap v. Buffered||
|4 Thread Count|17.28%|
|8 Thread Count|21.73%|
|16 Thread Count|23.82%|
|24 Thread Count|31.01%|
|36 Thread Count|36.52%|
|54 Thread Count|27.72%|
|81 Thread Count|17.18%|
|121 Thread Count|11.88%|
|181 Thread Count|-3.39%|
|271 Thread Count|-4.47%|
|Windows Mmap v. Buffered|
|4 Thread Count|10.25%|
|8 Thread Count|7.81%|
|16 Thread Count|10.72%|
|24 Thread Count|13.88%|
|36 Thread Count|17.48%|
|54 Thread Count|28.81%|
|81 Thread Count|40.49%|
|121 Thread Count|40.78%|
|181 Thread Count|35.00%|
|271 Thread Count|33.00%|
This is controlling for dataset, stress application, and environment to some
degree - clean non-tuned installs of win7 vs. ubuntu 14.04, so no changes in
kernel params, file cache settings, kernel scheduler on either platform, etc.
Previous testing had the stress client running on the same host as the C*
instance which unfavorably reflected on Windows as looks to be CPU-bound at a
much lower thread-count than linux.
It's somewhat interesting to note that buffered I/O uses roughly 35% more
privileged cpu-time than memory-mapped, whereas user, interrupt, and all other
processor counters show comparable load between the two configurations.
> Remove mmap'ed i/o from read path
> ---------------------------------
>
> Key: CASSANDRA-6890
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6890
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Joshua McKenzie
> Assignee: Joshua McKenzie
> Priority: Minor
> Fix For: 3.0
>
> Attachments: mmap_gc.jpg, mmap_jstat.txt, mmap_perf.txt,
> nommap_gc.jpg, nommap_jstat.txt
>
>
> Since we actively unmap unreferenced SSTR's and also copy data out of those
> readers on the read path, the current memory mapped i/o is a lot of
> complexity for very little payoff. Clean out the mmapp'ed i/o on the read
> path.
--
This message was sent by Atlassian JIRA
(v6.2#6252)