[
https://issues.apache.org/jira/browse/CASSANDRA-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5039:
--------------------------------------
Priority: Minor (was: Major)
Labels: performance (was: )
> 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: Bug
> Components: Core
> 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.2#6252)
