Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] TCK "Promotion"

The costs were based on last year's EE8 push. It was simply the maximum peak resource utilization. We have no insight into any details of the costs.

On Thu, Aug 6, 2020 at 9:43 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On 8/5/20 8:41 PM, David Blevins wrote:
>
> On the last note, we spent an additional $30k on TCK infrastructure this
> year and we're also moving our release timeline out, so we've exceeded
> both budget and deadlines making any "just a bit more time and another
> run" less attractive.

David, I meant to thank you for this information.  I had heard that we
are overusing the https://ci.eclipse.org/jakartaee-tck infrastructure
but I didn't yet hear any details.  I did set a low priority since we
can continue testing but now that we have heard the cost, perhaps we
should raise the priority.

I did create https://bugs.eclipse.org/bugs/show_bug.cgi?id=565646
requesting more information that might help us understand which
resources we are using too much of exactly.  We do have some really high
-Xmx settings that would be good to lower, but I'm not really sure how
that correlates to the additional 30k at this point.

Does anyone more familar with our costs know if we are over using
CPU/memory or storage?

Some high memory settings that I noticed before that may need tuning:

1.  in Jenkinsfile, for jakartaeetck-ci, we default
JAVA_TOOL_OPTIONS=-Xmx6G
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L142

Does anyone know which JVM process was hitting OOM that led to this
setting?  Having this information shared here will help us understand
what might need to change (assuming reducing memory use helps reduce our
bill).

2.  run_jakartaeetck.sh script increases max memory to
-Xmx4096m/-Xmx2048m for EJB30 tests

https://github.com/eclipse-ee4j/jakartaee-tck/pull/412#discussion_r466385753
mentions the idea of splitting up some largish Platform TCK test groups
which could help reduce the need to set a high JVM memory size.

https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/docker/run_jakartaeetck.sh#L249

3. docker/build_jakartaeetck.sh script sets ANT_OPTS="-Xmx2G ...", seems
pretty high (if the JVM memory heap grows to that level).

The same for docker/build_standalone-tcks.sh.

4. install/jakartaee/bin/ts.jte sets ri.jvm.options + vi.jvm.options to
-mx4096m.

5. Also in Jenkinsfile, it would be good to discover a lower JNLP memory
setting that stills works (currently using memory: "3Gi")

https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L134

6. Also in Jenkins file, for jakartaeetck-ci, we set memory: "10Gi"
which I think is used by each OS/VM/container actually running TCK
tests, it would be nice to get this down to "5Gi" if memory factors into
the high cost.  We also use 2 CPU cores as well, I always use 1 CPU when
setting up virtualization but 2 CPU cores seems okay if that doesn't
increase our costs.

https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L146

7.  Also in Jenkins file, for email, we set memory: "2Gi", not sure that
we need that much for the OS/VM/container running the mail server
(jakartaee/cts-mailserver)

https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L159

Thanks,
Scott

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top