You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Vivek Ratan (JIRA)" <ji...@apache.org> on 2009/01/09 14:15:59 UTC
[jira] Commented: (HADOOP-5003) When computing absoluet guaranteed
capacity (GC) from a percent value, Capacity Scheduler should round up
floats, rather than truncate them.
[ https://issues.apache.org/jira/browse/HADOOP-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662358#action_12662358 ]
Vivek Ratan commented on HADOOP-5003:
-------------------------------------
I'll put a patch up once we commit other pending patches for the Scheduler, as the code changes the core scheduler file which is changed by the other patches too.
> When computing absoluet guaranteed capacity (GC) from a percent value, Capacity Scheduler should round up floats, rather than truncate them.
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-5003
> URL: https://issues.apache.org/jira/browse/HADOOP-5003
> Project: Hadoop Core
> Issue Type: Bug
> Reporter: Vivek Ratan
> Priority: Minor
>
> The Capacity Scheduler calculates a queue's absolute GC value by getting its percent of the total cluster capacity (which is a float, since the configured GC% is a float) and casting it to an int. Casting a float to an int always rounds down. For very small clusters, this can result in the GC of a queue being one lower than what it should be. For example, if Q1 has a GC of 50%, Q2 has a GC of 40%, and Q3 has a GC of 10%, and if the cluster capacity is 4 (as we have, in our test cases), Q1's GC works out to 2, Q2's to 1, and Q3's to 0 with today's code. Q2's capacity should really be 2, as 40% of 4, rounded up, should be 2.
> Simple fix is to use Math.round() rather than cast to an int.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.