cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-1632) Thread workflow and cpu affinity
Date Tue, 28 Dec 2010 16:20:46 GMT

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

T Jake Luciani edited comment on CASSANDRA-1632 at 12/28/10 11:20 AM:
----------------------------------------------------------------------

Regarding 2)  I think it's possible to set the affinity on a particular thread in linux using
the taskset command.  

Basically you get the native thread's LWPID: "ps -Lf ${pid}"  and call taskset with each of
these to pin them to a given core. This could be done on startup.

 

      was (Author: tjake):
    Regarding 2)  I think it's possible to set the affinity on a particular thread in linux
using the taskset command.  

Basically you get the native thread's PPID: "ps -Lf ${pid}"  and call taskset with each of
these to pin them to a given core. This could be done on startup.

 
  
> Thread workflow and cpu affinity
> --------------------------------
>
>                 Key: CASSANDRA-1632
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1632
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Chris Goffinet
>             Fix For: 0.7.1
>
>
> Here are some thoughts I wanted to write down, we need to run some serious benchmarks
to see the benefits:
> 1) All thread pools for our stages use a shared queue per stage. For some stages we could
move to a model where each thread has its own queue. This would reduce lock contention on
the shared queue. This workload only suits the stages that have no variance, else you run
into thread starvation. Some stages that this might work: ROW-MUTATION.
> 2) Set cpu affinity for each thread in each stage. If we can pin threads to specific
cores, and control the workflow of a message from Thrift down to each stage, we should see
improvements on reducing L1 cache misses. We would need to build a JNI extension (to set cpu
affinity), as I could not find anywhere in JDK where it was exposed. 
> 3) Batching the delivery of requests across stage boundaries. Peter Schuller hasn't looked
deep enough yet into the JDK, but he thinks there may be significant improvements to be had
there. Especially in high-throughput situations. If on each consumption you were to consume
everything in the queue, rather than implying a synchronization point in between each request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message