[
https://issues.apache.org/jira/browse/CASSANDRA-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-4292:
--------------------------------------
Attachment: 4292-v2.txt
v2 attached.
This version introduces new way of specifying # of threads per disk. In
cassandra.yaml, {{data_file_directory}} now takes additional parameter in the
following format(num threads follows after ':').
{code}
data_file_directories:
- /mnt/d1/data:1
- /mnt/d1/data:3
{code}
If ':#' is omitted, it defaults to 1, so we can preserve backward
compatibility. {{memtable_flush_writers}} is removed from yaml.
In this version, compaction also uses disk bound task executor to write
sstables. Directory is chosen based on available space in both queue and disk.
bq. probably cleaner to use a Map for the new getLocationForDisk method
I did not modify to Map, since I think it is redundant and looping through few
directories does not make difference.
> 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-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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira