You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Vladimir Rodionov (JIRA)" <ji...@apache.org> on 2015/08/20 02:01:38 UTC
[jira] [Created] (HBASE-14263) ExploringCompactionPolicy logic
around file selection is broken
Vladimir Rodionov created HBASE-14263:
-----------------------------------------
Summary: ExploringCompactionPolicy logic around file selection is broken
Key: HBASE-14263
URL: https://issues.apache.org/jira/browse/HBASE-14263
Project: HBase
Issue Type: Bug
Reporter: Vladimir Rodionov
Assignee: Vladimir Rodionov
Fix For: 2.0.0
It seems that logic around selection of store file candidates is broken:
{code}
// Compute the total size of files that will
// have to be read if this set of files is compacted.
long size = getTotalStoreSize(potentialMatchFiles);
// Store the smallest set of files. This stored set of files will be used
// if it looks like the algorithm is stuck.
if (mightBeStuck && size < smallestSize) {
smallest = potentialMatchFiles;
smallestSize = size;
}
if (size > comConf.getMaxCompactSize()) {
continue;
}
++opts;
if (size >= comConf.getMinCompactSize()
&& !filesInRatio(potentialMatchFiles, currentRatio)) {
continue;
}
{code}
This is from applyCompactionPolicy method. As you can see, both min compaction size and max compaction size are applied to a *selection* of files and not to individual files. It mostly works as expected only because nobody seems using non-default hbase.hstore.compaction.max.size, which is Long.MAX_VALUE and it is not that easy to figure out what is going on on an opposite side (why small files do not get included?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)