cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4292) Per-disk I/O queues
Date Mon, 30 Jul 2012 17:33:35 GMT


Jonathan Ellis commented on CASSANDRA-4292:

- need to use a single DiskWriter for both compaction and flushing or we lose on most of the
benefits here.  One solution: rename CompactionManager to IOManager, and use that.  Another
could be to move it into StorageService.
- compactionexecutor needs to be cleaned up since it's no longer serving the executor role.
 again, cleanup could be straightforward if we morph CM into IOManager (and merge CompactionExecutor
+ DiskWriter).  Could be nice to get the kind of progress reporting on flushes that we now
have on compaction.
- DiskWriter: Can we use CopyOnWriteArrayList instead of synchronized block?

> Per-disk I/O queues
> -------------------
>                 Key: CASSANDRA-4292
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Yuki Morishita
>             Fix For: 1.2
>         Attachments: 4292-v2.txt, 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:!default.jspa
For more information on JIRA, see:


View raw message