Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 16 Mar 2017 14:25:42 +0000 (UTC)
From: "Kahlil Oppenheimer (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13046858.1488256805000.38043.1489674342052@Atlassian.JIRA>
In-Reply-To: <JIRA.13046858.1488256805000@Atlassian.JIRA>
References: <JIRA.13046858.1488256805000@Atlassian.JIRA> <JIRA.13046858.1488256805488@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-17706) TableSkewCostFunction improperly
 computes max skew
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 16 Mar 2017 14:25:49 -0000


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

Kahlil Oppenheimer commented on HBASE-17706:
--------------------------------------------

[~tedyu] I just rebased the patch and resubmitted it. It might break on one test in TestStochasticLoadBalancer2 until HBASE-17707 is merged in (which contained a fix that affects this test).

> 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)