[ https://issues.apache.org/jira/browse/HBASE-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969113#action_12969113 ]
HBase Review Board commented on HBASE-3308: ------------------------------------------- Message from: "Jean-Daniel Cryans" <jdcry...@apache.org> bq. On 2010-12-07 17:02:49, stack wrote: bq. > /branches/0.90/src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java, line 400 bq. > <http://review.cloudera.org/r/1273/diff/1/?file=17980#file17980line400> bq. > bq. > Why not have an upper bound? If 100 files thats 100 threads doing FS operations. I bet if you had upper bound of 10 on the executorservice, it complete faster than an unbounded executorservice? I think we are already bounded by hbase.hstore.blockingStoreFiles - Jean-Daniel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/1273/#review2043 ----------------------------------------------------------- > SplitTransaction.splitStoreFiles slows splits a lot > --------------------------------------------------- > > Key: HBASE-3308 > URL: https://issues.apache.org/jira/browse/HBASE-3308 > Project: HBase > Issue Type: Improvement > Reporter: Jean-Daniel Cryans > Priority: Critical > Fix For: 0.92.0 > > > Recently I've been seeing some slow splits in our production environment > triggering timeouts, so I decided to take a closer look into the issue. > According to my debugging, we spend almost all the time it takes to split on > creating the reference files. Each file in my testing takes at least 300ms to > create, and averages around 600ms. Since we create two references per store > file, it means that a region with 4 store file can easily take up to 5 > seconds to split just to create those references. > An intuitive improvement would be to create those files in parallel, so at > least it wouldn't be much slower when we're splitting a higher number of > files. Stack left the following comment in the code: > {noformat} > // TODO: If the below were multithreaded would we complete steps in less > // elapsed time? St.Ack 20100920 > {noformat} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.