[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] Being green and reducing our Jenkins CI usage...
|
This week, the Steering Committee approved funding that will allow the
EE4J working group to use, up to the resource pack requirements
(Basically VM allocations) that were measured and allocated, based on
our peak usage, back in September of last year. Hopefully this will
suffice for the rest of this calendar year. If we can lower our usage
requirements through various kinds of optimizations, that would be
excellent.
Personally, I hope that this funding decision will allow us focus our
efforts on achieving the release requirements and not so much on trying
to improve our efficiency. That doesn't mean ignore efficiency and
certainly we cannot be wasteful. It just means that resource utilization
is not the first priority. I think all the committees are clear that the
schedule is the first priority for now.
Thanks,
-- Ed
On 7/9/2020 8:38 AM, Scott Marlow wrote:
On 7/7/20 2:05 PM, Scott Marlow wrote:
Hi,
I heard some general feedback that we are consuming more resources
than expected with our jakartaee-tck environment. I don't have
specifics at the moment but am thinking that we could update
the jakartaeetck-nightly-build-master [1] job to only run if a change
was merged to the TCK repo [2]. Any volunteers from the committers
to work on this change? Only the committers have permissions to
update the Jenkins job [1] to poll the SCM (git).
Ideas are welcome :)
The jakartaeetck-nightly-build-master [1] currently runs every night,
regardless of whether there are any changes made to the Platform TCK
repo. We could update jakartaeetck-nightly-build-master [1] to
reference the jakartaee-tck git repo [2], however that adds the
additional cost of cloning the git repo (such that building the
Platform TCK takes even more time versus some time savings on days
when there are no TCK code changes).
I'm leaning towards trying to add the git repo [2] to the
jakartaeetck-nightly-build-master [1] job, so that we reduce the
overall time consumed.
Scott
I also have been thinking about further changes to the JNLP memory
settings in [3]. More specifically, we could try reducing
the -Xmx2048m setting to a lower value that is still higher than the
-Xmx512m that we previously used, it is guesswork mostly. If we
switched to -Xmx1024m, we likely will use more cpu (e.g. running more
frequent GCs) but that might free up other VM/OS level memory for
kernel use. We would need to measure the before/after result of such
a change. If the TCK runs are faster with this change, we would it
keep it. If the TCK runs are slower or have more test failures, we
would revert it.
Scott
[1]
https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-build-master/
[2] https://github.com/eclipse-ee4j/jakartaee-tck
[3]
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L130
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
