cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
Date Mon, 29 Jun 2015 12:26:05 GMT

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

Jonathan Ellis commented on CASSANDRA-9318:
-------------------------------------------

* default timeout is 2s not 10, so actually fine in your example of 300MB vs 150MB/s  x 2s
* but we can easily set a higher limit on MS heap -- maybe as high as 1/8 heap as default
which gives us a *lot* of room for 8GB heap
* you don't see a complete halt until capacity's worth of requests timeout all at once, because
you don't get an entire capacity load accepted at once.  it's more continuous than discrete
-- you pause until the oldest expire, accept more, pause until the oldest expire, etc.  so
you make slow progress as load shedding can free up memory.  thus, load shedding is complementary
to flow control.
* aggressively load shedding for "outlier" nodes is a good idea that we should follow up on
in another ticket.  again, current behavior of continuing to accept requests until we fall
over is worse than imposing flow control, so we should start with that [flow control] in 2.1
and make further improvements in 2.2.

> Bound the number of in-flight requests at the coordinator
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-9318
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 2.1.x, 2.2.x
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster by bounding
the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding bytes and requests
and if it reaches a high watermark disable read on client connections until it goes back below
some low watermark.
> Need to make sure that disabling read on the client connection won't introduce other
issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message