[
https://issues.apache.org/jira/browse/CASSANDRA-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436059#comment-13436059
]
Jonathan Ellis commented on CASSANDRA-4292:
-------------------------------------------
Your instincts were better than mine: combining compaction and flush i/o into a
single executor was a mistake. We could band-aid it by adding some kind of
semaphore mechanism to make sure we always leave at least one thread free for
flushing but this still won't let us max out on flushing temporarily at the
expense of compaction, without introducing extremely complicated preemption
logic.
So, color me convinced that we need to keep separate executors for flush and
compaction.
Additionally, the more I think about it the less I think the DBT abstraction is
what we want here. Or at a higher level: I don't think we want to be that
strict about one thread per disk. Which was my fault in the first place, sorry!
If we instead just follow the above disk prioritization logic, we'll still get
effectively thread-per-disk until disks start to run out of space. But having
a (standard) flexible pool of threads means that we generalize much better to
SSDs, where having substantially more threads than disks makes sense (since
compaction becomes CPU bound).
So I think we can simplify our approach a lot, perhaps by having a global
Directory state that tracks space remaining and how many i/o tasks are running
on each, that we can use when handing out flush and compaction targets. The
executor architecture won't need to change. (May want to introduce a
DirectoryBoundRunnable abstraction, whose run method encapsulates updating i/o
task count and space free after running the flush/compaction, but without
trying it I'm not sure if that actually works as imagined.)
> 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, 4292-v2.txt, 4292-v3.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
