You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2014/07/17 01:15:07 UTC
[jira] [Resolved] (HBASE-3106) a temporary solution of multi-thread
compaction for 0.20.6
[ https://issues.apache.org/jira/browse/HBASE-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Purtell resolved HBASE-3106.
-----------------------------------
Resolution: Not a Problem
> a temporary solution of multi-thread compaction for 0.20.6
> ----------------------------------------------------------
>
> Key: HBASE-3106
> URL: https://issues.apache.org/jira/browse/HBASE-3106
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Affects Versions: 0.20.6
> Environment: 1master, 7 region servers, 4 * 7 clients(all clients run on region server host), sequential put
> configuration of each host is:
> memory: 16G (region server uses 10G)
> disk: 12T
> cpu: 8 core
> Reporter: andychen
> Attachments: multithread-compaction-0.20.6-v2.patch, multithread-compaction-0.20.6.patch
>
>
> Each region's memtable size is 64M, global memtable limit is 4G on one region server
> In heavy write scenario, especially disable WAL, sequential put fills memtable to full very quickly, and will generates too many storefiles in a short time.
> Then there are more and more compaction tasks put into compactionQueue, single thread excutes compaction task too slowly, finally forms a vicious cycle.
> This will block some region's data importing for a long time
> We simplely using ThreadPoolExecutor as multi-thread compaction sulution
> (As we know, 0.90 or 0.92 will optimize memflush, compaction, open, close...etc using multi-thread, but this magnificent version hasn't bee released yet)
--
This message was sent by Atlassian JIRA
(v6.2#6252)