[
https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241215#comment-14241215
]
Benedict commented on CASSANDRA-8449:
-------------------------------------
CASSANDRA-7705 is really designed for situations where we know there won't be
loads in-flight; i'd prefer not to reintroduce excessive long-lifetime
reference counting onto the read critical path (we don't ref count sstable
readers anymore, since CASSANDRA-6919).
All we're doing here is delaying when we unmap the file until a time it is
known to be unused, so we could create a global OpOrder that guards against
this; all requests that hit the node are guarded by the OpOrder for their
entire duration, and only once _all_ requests that started prior to _thinking_
the data is free do we actually free it. Typically I would not want to use this
approach for guarding operations that could take arbitrarily long, but really
all we're sacrificing is virtual address space, so being delayed more than you
expect (even excessively) should not noticeably impact system performance, as
the OS can choose to drop those pages on the floor, keeping only the mapping
overhead.
> Allow zero-copy reads again
> ---------------------------
>
> Key: CASSANDRA-8449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8449
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Priority: Minor
> Labels: performance
> Fix For: 3.0
>
>
> We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads
> accessing a ByteBuffer when the data was unmapped by compaction. Currently
> this code path is only used for uncompressed reads.
> The actual bytes are in fact copied to the client output buffers for both
> netty and thrift before being sent over the wire, so the only issue really is
> the time it takes to process the read internally.
> This patch adds a slow network read test and changes the tidy() method to
> actually delete a sstable once the readTimeout has elapsed giving plenty of
> time to serialize the read.
> Removing this copy causes significantly less GC on the read path and improves
> the tail latencies:
> http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688f&metric=gc_count&operation=2_read&smoothing=1&show_aggregates=true&xmin=0&xmax=109.34&ymin=0&ymax=5.5
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
