cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4292) Per-disk I/O queues
Date Mon, 23 Jul 2012 19:38:34 GMT

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

Jonathan Ellis commented on CASSANDRA-4292:
-------------------------------------------

Looks reasonable to me so far.

A couple points:

- we'll want to prefer (1) disks that have no current writes, then (2) disks with the least
projected data (including the estimated size of currently active writes)
- compaction should use this executor as well

Nit: probably cleaner to use a Map for the new getLocationForDisk method
                
> Per-disk I/O queues
> -------------------
>
>                 Key: CASSANDRA-4292
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4292
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Yuki Morishita
>             Fix For: 1.2
>
>         Attachments: 4292.txt
>
>
> As noted in CASSANDRA-809, we have a certain amount of flush (and compaction) threads,
which mix and match disk volumes indiscriminately.  It may be worth creating a tight thread
-> disk affinity, to prevent unnecessary conflict at that level.
> OTOH as SSDs become more prevalent this becomes a non-issue.  Unclear how much pain this
actually causes in practice in the meantime.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message