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

Bharath Vissapragada commented on HBASE-23779:
----------------------------------------------

[~stack] Do we need to bump up the ulimits after these changes? The jobs are 
running into proc limits (example below). This is happening in the pre-commits 
too.

{noformat}
Error Message
java.lang.Exception: java.lang.OutOfMemoryError: unable to create new native 
thread
Stacktrace
java.io.IOException: java.lang.Exception: java.lang.OutOfMemoryError: unable to 
create new native thread
        at 
org.apache.hadoop.hbase.replication.multiwal.TestReplicationKillMasterRSCompressedWithMultipleAsyncWAL.setUpBeforeClass(TestReplicationKillMasterRSCompressedWithMultipleAsyncWAL.java:42)
{noformat}

Example: 
https://builds.apache.org/job/HBase%20Nightly/job/master/1623//testReport/junit/org.apache.hadoop.hbase.replication.multiwal/TestReplicationKillMasterRSCompressedWithMultipleAsyncWAL/health_checks___yetus_jdk8_hadoop2_checks___/

> 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: addendum2.patch, 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