Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <89891578.1261338978165.JavaMail.jira@brutus>
Date: Sun, 20 Dec 2009 19:56:18 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Updated: (HBASE-2021) Add compaction details to master UI
In-Reply-To: <487332857.1259691621014.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Purtell updated HBASE-2021:
----------------------------------

    Status: Open  (was: Patch Available)

The attached patch is corrupt. Cancelling patch. Resubmit when ready.

{noformat}
[...]
patching file src/webapps/master/master.jsp
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file src/webapps/master/master.jsp.rej
missing header for unified diff at line 263 of patch
can't find file to patch at input line 263
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|
|   import="org.apache.hadoop.hbase.master.HMaster"
|
|   import="org.apache.hadoop.hbase.HConstants"
|
|   import="org.apache.hadoop.hbase.master.MetaRegion"
|
--------------------------
[...]
{noformat}

> Add compaction details to master UI
> -----------------------------------
>
>                 Key: HBASE-2021
>                 URL: https://issues.apache.org/jira/browse/HBASE-2021
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: Lars George
>            Assignee: Lars George
>            Priority: Minor
>             Fix For: 0.21.0
>
>         Attachments: HBASE-2021.patch
>
>
> There are two issues with this, first to detect that there is a compaction needed. You can currently use the little helper util that checks if a table has at least one colfam with more than one store file. I though about scanning all tables and all colfams in each and then compute the "fragmentation" ratio as a percentage of colfams with more than one store to the total number of colfams. That gives a "Table xyz is 33% fragmented" output. While minor percentage are normal under insert operations it is still important to know how bad the fragmentation is overall.
> Another idea is to weigh the number of files per store too, so that if you have two per colfam it is considered "low" and if you have more, for example 6-8 it is considered "high". Not sure how that can be done yet but noting the idea down here.
> Of course seeing the .META. fragmentation is useful to quickly debug performance issues (as JD told me on IRC).
> The other issue is that when you have started a compaction you have no idea how far it is and if it is still in progress. One indication of course is the above value. If it is 0% then all is done. But if you are at say 23%, is it still compacting? We could have a simple status that compactions are still in progress.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.