[
https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220017#comment-14220017
]
Jeremiah Jordan commented on CASSANDRA-7386:
--------------------------------------------
bq. just because of reservation? oops
oh sorry, mis-understood you. The problem with reservations was
CASSANDRA-5605. We would end up reserving the whole disk, so flushing couldn't
happen, and then the heap would fill up, and you would OOM. Because we
reserved the max possible space, but for workloads with overwrites, the
resulting file is way smaller than the reservation, so we didn't actually need
all that space. Basically we were declaring "disk full", before the disk was
actually full. The other problem is that when reserving space, if multiple
compactions are in progress, you reserve the max needed by all of them. But
they finish at different times, and when they finish all the old files get
removed. So again you are declaring "disk full" when it will not actually be
full.
> 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-2.0-v3.txt, 7386-2.0-v4.txt, 7386-2.0-v5.txt,
> 7386-2.1-v3.txt, 7386-2.1-v4.txt, 7386-2.1-v5.txt, 7386-v1.patch,
> 7386v2.diff, Mappe1.ods, mean-writevalue-7disks.png,
> patch_2_1_branch_proto.diff, sstable-count-second-run.png,
> test1_no_patch.jpg, test1_with_patch.jpg, test2_no_patch.jpg,
> test2_with_patch.jpg, test3_no_patch.jpg, test3_with_patch.jpg,
> test_regression_no_patch.jpg, test_regression_with_patch.jpg
>
>
> 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)
