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

Nick Dimiduk commented on HBASE-23779:
--------------------------------------

[~busbey] any objection if I modify the Jenkins script as follows?

{noformat}
diff --git a/dev-support/PreCommit-HBase-Build.sh 
b/dev-support/PreCommit-HBase-Build.sh
index f1494978ea..798b829c3d 100644
--- a/dev-support/PreCommit-HBase-Build.sh
+++ b/dev-support/PreCommit-HBase-Build.sh
@@ -82,8 +82,8 @@ else
     tar xvpf yetus.tar.gz
     prerelease_dirs=(${TEST_FRAMEWORK}/${YETUS_PRERELEASE_GITHUB/\//-}-*)
   fi
-  TESTPATCHBIN=${prerelease_dirs[0]}/precommit/test-patch.sh
-  TESTPATCHLIB=${prerelease_dirs[0]}/precommit
+  TESTPATCHBIN=${prerelease_dirs[0]}/precommit/src/main/shell/test-patch.sh
+  TESTPATCHLIB=${prerelease_dirs[0]}/precommit/src/main/shell
 fi
 
 if [[ "true" = "${DEBUG}" ]]; then
{noformat}

> Up the default fork count to make builds complete faster; make count relative 
> to CPU count
> ------------------------------------------------------------------------------------------
>
>                 Key: HBASE-23779
>                 URL: https://issues.apache.org/jira/browse/HBASE-23779
>             Project: HBase
>          Issue Type: Bug
>          Components: test
>            Reporter: Michael Stack
>            Assignee: Michael Stack
>            Priority: Major
>             Fix For: 3.0.0, 2.3.0
>
>         Attachments: test_yetus_934.0.patch
>
>
> Tests take a long time. Our fork count running all tests are conservative -- 
> 1 (small) for first part and 5 for second part (medium and large). Rather 
> than hardcoding we should set the fork count to be relative to machine size. 
> Suggestion here is 0.75C where C is CPU count. This ups the CPU use on my box.
> Looking up at jenkins, it seems like the boxes are 24 cores... at least going 
> by my random survey. The load reported on a few seems low though this not 
> representative (looking at machine/uptime).
> More parallelism willl probably mean more test failure. Let me take a look 
> see.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to