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

Benedict commented on CASSANDRA-7402:
-------------------------------------

We should be able to get to a place where data is streamed from disk to the 
network in small chunks (with large cells being broken up), and a coordinator 
could potentially receive a stream-digest from > CL.ONE queries that should be 
in-sync. The problem then shifts exclusively to what kind of CQL post 
processing we do, such as if we support sorting the data, which might require 
it all to be buffered (but this could be buffered to disk for an external sort).

This general principle of streaming controlled quantities of data for each 
request is definitely something I want to head towards, and hope to make easier 
with the refactor(s) we're in the process of for the internal storage apis.

> limit the on heap memory available to requests
> ----------------------------------------------
>
>                 Key: CASSANDRA-7402
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7402
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: T Jake Luciani
>             Fix For: 3.0
>
>
> When running a production cluster one common operational issue is quantifying 
> GC pauses caused by ongoing requests.
> Since different queries return varying amount of data you can easily get your 
> self into a situation where you Stop the world from a couple of bad actors in 
> the system.  Or more likely the aggregate garbage generated on a single node 
> across all in flight requests causes a GC.
> We should be able to set a limit on the max heap we can allocate to all 
> outstanding requests and track the garbage per requests to stop this from 
> happening.  It should increase a single nodes availability substantially.
> In the yaml this would be
> {code}
> total_request_memory_space_mb: 400
> {code}
> It would also be nice to have either a log of queries which generate the most 
> garbage so operators can track this.  Also a histogram.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to