[
https://issues.apache.org/jira/browse/CASSANDRA-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128651#comment-14128651
]
Benedict commented on CASSANDRA-7907:
-------------------------------------
The _pinning_ is a secondary concern that I definitely want to leave optional
(i.e. implement it, but leave it configurable, and default to off until we
collect extensive data on good widely applicable defaults). I don't expect the
user to taskset, however; we'd do this for the user, but let them specify the
cpu id in the yaml if they think they can do a better job of it.
bq. do we have reason to believe that we're bottle-necking on this
It's difficult to benchmark networking overheads accurately, but it's a
significant portion (perhaps majority) of our cpu time for in-memory workloads.
Anything we can do to reduce this we should explore.
> Determine how many network threads we need for native transport
> ---------------------------------------------------------------
>
> Key: CASSANDRA-7907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7907
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benedict
> Priority: Minor
>
> With the introduction of CASSANDRA-4718, it is highly likely we can cope with
> just _one_ network IO thread. We could even try pinning it to a single
> (optionally configurable) core, and (also optionally) pin all other threads
> to a different core, so that we can guarantee extremely prompt execution (and
> if pinned to the correct core the OS uses for managing the network, improve
> throughput further).
> Testing this out will be challenging, as we need to simulate clients from
> lots of IPs. However, it is quite likely this would reduce the percentage of
> time spent in kernel networking calls, and the amount of context switching.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
