[
https://issues.apache.org/jira/browse/CASSANDRA-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128732#comment-14128732
]
Joshua McKenzie commented on CASSANDRA-7907:
--------------------------------------------
I'd want some evidence that pinning to cores is going to give us a measurable
benefit before adding it to the code-base, rather than adding it and leaving it
disabled until we can come up with good defaults for it. I agree with the
conclusion that we likely spend a significant portion of our cpu time on
networking w/in-memory workloads but I'd like to see some quantification of
that before we start writing code to address it.
Good point on us doing the pinning from within our context - that makes that
far more palatable from an ops perspective. We don't gain the benefit of true
isolation of our processes from kernel preemption in the scheduler but that
tends to be a bigger concern on lower index cores (from my experience) so
that's something we can soft-work around.
> 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)
