Hudson commented on HBASE-13884:

Results for branch HBASE-19064
        [build #90 on 
(x) *{color:red}-1 overall{color}*
details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 

(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 

(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (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

Reply via email to