[
https://issues.apache.org/jira/browse/HBASE-17706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kahlil Oppenheimer updated HBASE-17706:
---------------------------------------
Attachment: HBASE-17706-06.patch
> TableSkewCostFunction improperly computes max skew
> --------------------------------------------------
>
> Key: HBASE-17706
> URL: https://issues.apache.org/jira/browse/HBASE-17706
> Project: HBase
> Issue Type: Bug
> Components: Balancer
> Affects Versions: 1.2.0
> Environment: CentOS Derivative with a derivative of the 3.18.43
> kernel. HBase on CDH5.9.0 with some patches. HDFS CDH 5.9.0 with no patches.
> Reporter: Kahlil Oppenheimer
> Assignee: Kahlil Oppenheimer
> Priority: Minor
> Labels: patch
> Attachments: HBASE-17706-01.patch, HBASE-17706-02.patch,
> HBASE-17706-03.patch, HBASE-17706-04.patch, HBASE-17706-05.patch,
> HBASE-17706-06.patch, HBASE-17706.patch
>
>
> We noticed while running unit tests that the TableSkewCostFunction computed
> cost did not change as the balancer ran and simulated moves across the
> cluster. After investigating, we found that this happened in particular when
> the cluster started out with at least one table very strongly skewed.
> We noticed that the TableSkewCostFunction depends on a field of the
> BaseLoadBalancer.Cluster class called numMaxRegionsPerTable, but this field
> is not properly maintained as regionMoves are simulated for the cluster. The
> field only ever increases as the maximum number of regions per table
> increases, but it does not decrease as the maximum number per table goes down.
> This patch corrects that behavior so that the field is accurately maintained,
> and thus the TableSkewCostFunction produces a more correct value as the
> balancer runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
