[
https://issues.apache.org/jira/browse/LUCENE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022347#comment-17022347
]
Dawid Weiss commented on LUCENE-9160:
-------------------------------------
I never had a chance to experiment on those super-beefy machines but I'm sure
we can alter the defaults.
{code}
// Approximate a common-sense default for running gradle with parallel
// workers: half the count of available cpus but not more than 12.
def cpus = Runtime.runtime.availableProcessors()
def maxWorkers = (int) Math.max(1d, Math.min(cpus * 0.5d, 12))
def testsJvms = (int) Math.max(1d, Math.min(cpus * 0.5d, 4))
{code}
My machines quickly saturate I/O and memory bandwidth for higher test
parallelism, especially for Solr. The above is just off-the-top-off-my-head
default. It can be certainly improved.
> override heap / jvm params for tests in gradle build
> ----------------------------------------------------
>
> Key: LUCENE-9160
> URL: https://issues.apache.org/jira/browse/LUCENE-9160
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
> Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9160.patch, LUCENE-9160.patch
>
>
> Currently the gradle.properties that is generated lets you control the heap
> and flags for the gradle build jvms.
> But there is no way to control these flags for the actual forked VMs running
> the unit tests. For example, minHeap is hardcoded at 256m and maxHeap at
> 512m.
> I would like to change minHeap to 512m as well, for a fixed heap, and set
> some other jvm flags, such as {{-XX:+UseParallelGC}} so that my tests are not
> slow for silly reasons :)
> I think it is stuff jenkins CI would need as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
