You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Joshua McKenzie (JIRA)" <ji...@apache.org> on 2014/09/10 17:50:33 UTC

[jira] [Commented] (CASSANDRA-7907) Determine how many network threads we need for native transport

    [ https://issues.apache.org/jira/browse/CASSANDRA-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128625#comment-14128625 ] 

Joshua McKenzie commented on CASSANDRA-7907:
--------------------------------------------

Historically I've found that pinning network I/O to core 0 when using kernel-buffers (i.e. not kernel-bypass) gives you a measurable increase in performance.

That being said, do we have reason to believe that we're bottle-necking on this?  I ask because managing either tasksetting or cpusets on a large number of hosts (especially in environments with other processes on the box) can be a pretty big burden for ops.

> 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)