[
https://issues.apache.org/jira/browse/CASSANDRA-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121762#comment-14121762
]
Pavel Yaskevich commented on CASSANDRA-7594:
--------------------------------------------
[~philipthompson] Got it, I think I have an idea about what is going on, each
selector is being to greedy with shared pool and is trying to use all of the
core threads for it's workers. I'm attaching a new thrift-server jar, can you
please try it out?
> Disruptor Thrift server worker thread pool not adjustable
> ---------------------------------------------------------
>
> Key: CASSANDRA-7594
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7594
> Project: Cassandra
> Issue Type: Bug
> Reporter: Rick Branson
> Assignee: Pavel Yaskevich
> Fix For: 2.0.11
>
> Attachments: CASSANDRA-7594.patch,
> disruptor-thrift-server-0.3.6-SNAPSHOT.jar, jstack.txt
>
>
> For the THsHaDisruptorServer, there may not be enough threads to run blocking
> StorageProxy methods. The current number of worker threads is hardcoded at 2
> per selector, so 2 * numAvailableProcessors(), or 64 threads on a 16-core
> hyperthreaded machine. StorageProxy methods block these threads, so this puts
> an upper bound on the throughput if hsha is enabled. If operations take 10ms
> on average, the node can only handle a maximum of 6,400 operations per
> second. This is a regression from hsha on 1.2.x, where the thread pool was
> tunable using rpc_min_threads and rpc_max_threads.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
