[ https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241173#comment-14241173 ]
T Jake Luciani commented on CASSANDRA-8449: ------------------------------------------- Hmm yeah, if there was a pause before serializing the message and compaction was running you would still segfault. I was going to initially try using reference queue and weak references to track when the byte buffer but any .duplicate() would break that model. [~benedict] perhaps we can use CASSANDRA-7705 to manage this? > 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)