cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8449) Allow zero-copy reads again
Date Thu, 11 Dec 2014 11:54:13 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242439#comment-14242439
] 

Benedict commented on CASSANDRA-8449:
-------------------------------------

bq. Isn't the existing use of OpOrder technically "arbitrarily long" due to GC for instance

Any delay caused by GC to the termination of an OpOrder.Group is instantaneous from the point
of view of the waiter, since it is also delayed by GC

Either way, GC is not as arbitrarily long as I was referring to. Mostly I'm thinking about
network consumers that haven't died but are, perhaps, in the process of doing so (GC death
spiral), or where the network socket has frozen due to some other problem. i.e. where the
problem is isolated from the rest of the host's functionality, but by being guarded by an
OpOrder could conceivably cause the problem to infect the whole host's functionality. In reality
we can probably guard against most of the risk, but I would still be reticent to use this
scheme with that risk even minimally present without the ramifications being constrained as
they are here.


> 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)

Mime
View raw message