[
https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029949#comment-14029949
]
Chris Lohfink commented on CASSANDRA-7386:
------------------------------------------
Where I have seen it become a problem is more on high read throughput side. A
lot of reads + compactions (repairs) end up utilizing one disk pretty heavily
since it contains most of the data while other disk sitting comparatively idle
in iostat.
That said its an awful lotta maybe's and statistically not expected scenarios.
This may not be worth adding complexity for bottom %'s so feel free to mark as
wont fix if not worth it. Idea was more to put some threshold to only take the
likely performance hit to prevent the extreme cases. The 10% range difference
in the prototype impl attached is probably a bad example since I would see it
more around 25-30%.
An offline tool to balance things out after the fact may be a adequate solution
that can be developed outside of C* as well.
> JBOD threshold to prevent unbalanced disk utilization
> -----------------------------------------------------
>
> Key: CASSANDRA-7386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Chris Lohfink
> Priority: Minor
> Attachments: patch_2_1_branch_proto.diff
>
>
> Currently the pick the disks are picked first by number of current tasks,
> then by free space. This helps with performance but can lead to large
> differences in utilization in some (unlikely but possible) scenarios. Ive
> seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and
> STCS (although my suspicion is that STCS makes it worse since harder to be
> balanced).
> I purpose the algorithm change a little to have some maximum range of
> utilization where it will pick by free space over load (acknowledging it can
> be slower). So if a disk A is 30% full and disk B is 5% full it will never
> pick A over B until it balances out.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
