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

Robert Stupp commented on CASSANDRA-7386:
-----------------------------------------

Thanks for the explanation.
The root cause for CASSANDRA-5605 (as far as I understand) was that the sum of 
"space reserved for compactions" + "required space" did not match any disk.

I'm with with ignoring write-rate and read-rate - seems reasonable now. Any 
assumption about the "load" of the disks would depend on the usage of the data 
(which we cannot foresee ... yet).
Moving to something else that takes the "hotness" of the sstables into account 
is the way to go - but not easy. Requires a huge number of metric instances (. 
Not easy to combine these metrics as a "forecast" for compactions.

Yea - basically only the current disk space seems to be usable for this ticket. 
Will make it like that.

> JBOD threshold to prevent unbalanced disk utilization
> -----------------------------------------------------
>
>                 Key: CASSANDRA-7386
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Chris Lohfink
>            Assignee: Robert Stupp
>            Priority: Minor
>             Fix For: 2.1.3
>
>         Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods, 
> mean-writevalue-7disks.png, patch_2_1_branch_proto.diff, 
> sstable-count-second-run.png
>
>
> 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.3.4#6332)

Reply via email to