[
https://issues.apache.org/jira/browse/CASSANDRA-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984825#comment-13984825
]
Jonathan Ellis commented on CASSANDRA-6890:
-------------------------------------------
I think my assertion that "memory mapped i/o is a lot of complexity for very
little payoff" is not actually correct. With mmapped i/o, we copy from the
MappedByteBuffer into a HeapByteBuffer, but with buffered i/o, we copy from the
page cache into our buffered reader, then from the buffered reader into a
HeapByteBuffer. So we're still doing one more copy than mmap, even though mmap
isn't doing true zero-copy reads.
Now, we originally added that copy so that we didn't have to refcount each
sstable for the entire read life cycle. But [~benedict]'s new OpOrder gives us
a performant alternative: we can do zero copy reads, with a lightweight
refcount alternative that makes sure all reads are finished before unmapping an
sstable.
So getting rid of mmap is probably the wrong approach; instead, we should get
rid of buffered i/o, assuming nio2 has banished the Windows demons that
bedeviled mmap in the past. (Alternatively, we could roll our own O_DIRECT
buffering. mmap demonstrably confused the hell out of people -- "why does top
say C* is using 2TB of memory?" but O_DIRECT is probably as painful as it ever
was.)
> 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)
