You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2018/04/09 05:43:04 UTC

[jira] [Commented] (HBASE-13884) Fix Compactions section in HBase book

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

Hudson commented on HBASE-13884:
--------------------------------

Results for branch HBASE-19064
	[build #90 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-19064/90/]: (x) *{color:red}-1 overall{color}*
----
details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-19064/90//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-19064/90//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-19064/90//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Fix Compactions section in HBase book
> -------------------------------------
>
>                 Key: HBASE-13884
>                 URL: https://issues.apache.org/jira/browse/HBASE-13884
>             Project: HBase
>          Issue Type: Bug
>          Components: documentation
>            Reporter: Vladimir Rodionov
>            Assignee: stack
>            Priority: Trivial
>             Fix For: 3.0.0
>
>         Attachments: 0001-HBASE-13884-Fix-Compactions-section-in-HBase-book.patch
>
>
> http://hbase.apache.org/book.html#_compaction
> {quote}
> Being Stuck
> When the MemStore gets too large, it needs to flush its contents to a StoreFile. However, a Store can only have hbase.hstore.blockingStoreFiles files, so the MemStore needs to wait for the number of StoreFiles to be reduced by one or more compactions. However, if the MemStore grows larger than hbase.hregion.memstore.flush.size, it is not able to flush its contents to a StoreFile. If the MemStore is too large and the number of StoreFiles is also too high, the algorithm is said to be "stuck". The compaction algorithm checks for this "stuck" situation and provides mechanisms to alleviate it.
> {quote}
> According to source code, this "stuck" situation has nothingg to do with MemStore size. 
> {code}
> // Stuck and not compacting enough (estimate). It is not guaranteed that we will be
>     // able to compact more if stuck and compacting, because ratio policy excludes some
>     // non-compacting files from consideration during compaction (see getCurrentEligibleFiles).
>     int futureFiles = filesCompacting.isEmpty() ? 0 : 1;
>     boolean mayBeStuck = (candidateFiles.size() - filesCompacting.size() + futureFiles)
>         >= storeConfigInfo.getBlockingFileCount();
> {code}
> If the number of store files which are not being compacted yet exceeds blocking file count +(potentially)1 - we say that compaction may be stuck.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)