cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-5039) Make sure all instances of BlockingQueue have configurable and sane limits
Date Fri, 18 Mar 2016 14:28:33 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko resolved CASSANDRA-5039.
------------------------------------------
    Resolution: Won't Fix

> Make sure all instances of BlockingQueue have configurable and sane limits
> --------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5039
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5039
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 1.1.7
>            Reporter: Oleg Kibirev
>            Priority: Minor
>              Labels: performance
>
> Currently, most BlockingQueues in cassandra are creating without any limits (execution
stages) or with limits high enough to consume gigabytes of heap (PeriodicCommitLogExecutorService).
I have observed many cases where a single unresponsive node can bring down entire cluster
because others accumulate huge backlogs of operations.
> We need to make sure each queue is configurable through a yaml entry or a system property
and defaults are chosen so that any given queue doesn't consume more than 100M of heap. I
have successfully tested that adding these limits makes cluster resistant to heavy load or
a bad node.



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

Mime
View raw message