[
https://issues.apache.org/jira/browse/CASSANDRA-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951160#comment-13951160
]
Joshua McKenzie commented on CASSANDRA-6890:
--------------------------------------------
Good call - it looks like cassandra-stress doesn't have compression enabled on
the keyspaces it creates on write. Enabling compression gives very similar
results between the memory mapped and non-memory-mapped path. With that said -
performance differential provided by the memory-mapped code-path looks like
it's pretty substantial. Are we sure we want to remove this?
{code:title=Performance comparison}
mmap, trunk, compression off, 2G heap default ratio:
id, ops , op/s,adj op/s, key/s, mean, med,
.95, .99, .999, max, time
4 threadCount, 1166950 , 38737, 38737, 38737, 0.1, 0.1,
0.1, 0.1, 0.5, 22.4, 30.1
8 threadCount, 1619550 , 53634, -0, 53634, 0.1, 0.1,
0.2, 0.2, 0.7, 18.5, 30.2
16 threadCount, 1880100 , 61833, -0, 61833, 0.3, 0.2,
0.3, 0.5, 1.0, 31.7, 30.4
24 threadCount, 1951150 , 63979, -0, 63979, 0.4, 0.3,
0.4, 0.7, 1.7, 30.9, 30.5
36 threadCount, 1929450 , 63171, 63175, 63171, 0.6, 0.5,
0.7, 1.0, 3.2, 20.7, 30.5
54 threadCount, 1952900 , 63845, -0, 63845, 0.8, 0.8,
1.0, 1.5, 7.8, 31.0, 30.6
81 threadCount, 1890200 , 61689, 61721, 61689, 1.3, 1.3,
1.4, 2.3, 17.8, 33.0, 30.6
mmap, trunk, compression on, 2G heap default ratio:
id, ops , op/s,adj op/s, key/s, mean, med,
.95, .99, .999, max, time
4 threadCount, 609850 , 20237, 20237, 20237, 0.2, 0.2,
0.2, 0.3, 0.6, 28.8, 30.1
8 threadCount, 915400 , 30249, 30264, 30249, 0.3, 0.2,
0.4, 0.6, 1.2, 26.3, 30.3
16 threadCount, 936950 , 30638, 30661, 30638, 0.5, 0.3,
1.1, 6.0, 17.7, 94.0, 30.6
24 threadCount, 1003450 , 32452, -0, 32452, 0.7, 0.3,
1.9, 11.1, 26.5, 172.4, 30.9
36 threadCount, 1095500 , 34665, -0, 34665, 1.0, 0.3,
1.4, 23.3, 50.3, 129.1, 31.6
54 threadCount, 1083200 , 33426, -0, 33426, 1.6, 0.8,
1.8, 29.3, 63.5, 250.6, 32.4
81 threadCount, 1080850 , 32649, -0, 32649, 2.5, 1.6,
3.0, 32.5, 73.8, 784.0, 33.1
no-mmap, trunk, compression on, 2G heap default ratio:
id, ops , op/s,adj op/s, key/s, mean, med,
.95, .99, .999, max, time
4 threadCount, 581200 , 19273, 19287, 19273, 0.2, 0.2,
0.3, 0.3, 0.6, 24.0, 30.2
8 threadCount, 904150 , 29906, 29919, 29906, 0.3, 0.2,
0.4, 0.6, 1.1, 37.0, 30.2
16 threadCount, 998650 , 32770, -0, 32770, 0.5, 0.3,
1.4, 4.2, 8.7, 38.4, 30.5
24 threadCount, 1035250 , 33685, -0, 33685, 0.7, 0.3,
2.9, 9.1, 17.9, 44.2, 30.7
36 threadCount, 1059950 , 33396, -0, 33396, 1.1, 0.3,
1.5, 22.4, 47.5, 139.1, 31.7
54 threadCount, 1070250 , 32483, -0, 32483, 1.7, 0.8,
1.8, 28.7, 60.4, 253.5, 32.9
{code}
For read-heavy workloads on moderately sized data-sets, the option to keep
compression off to improve performance seems pretty compelling from all the #'s
I'm seeing.
> 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)
