[hibernate-dev] ORM Jenkins Builds

[Sanne Grinovero]

Hi Steve,
don't worry for the resources they consume. Each build job which we
run is fully isolated and running on independent hardware, so it's not
going to slow down any other build.

Since we now have a set of small servers, one each dedicated for a job
at a time, I've opted for low spec machines as an experiment. This
performance is however disappointing, we can try different types of
CPU/Memory/Disk categories.

The current specs of each build node are:
 2 CPUs
 3 GB of RAM
 18GB of root disk (of which 9GB available for our builds)
 50GB available to run various docker images and temporary databases
(allocated per job need)

They run Fedora 21, Cloud Edition.

As you can see, resources on a single build node are very limited -
especially space and memory.
But since there is no swap space configured (!) I expect that in case
the memory is not enough, it will crash (and therefore let us know)
rather than slow down.
It's possible though that since the ORM builds allocate 2GB of heap,
we're preventing the operating system from doing proper filesystem
caching.

currently we have:
GRADLE_OPTS="-Xmx2G -Xms2G -XX:MaxPermSize=512m"

I'm going to try to lower that, bear with me if there are failures. If
that doesn't work we can definitely replace these with larger
instances, it should take us just some minutes as it's all automated:
the only reason for me to be conservative is to make fair use of these
(free) resource, and also I'd like us to actually test for not needing
much ram - we can get there in smaller steps as needed of course.

Sanne

On 27 March 2015 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:
> I was curious why it took so long to run the master ORM jobs on the CI
> machine compared to running the job locally.  Locally I run `clean test` at
> the root prject quite often and it takes roughly 9-10 minutes.  The master
> CI jobs generally take 45-50 minutes to complete.
>
> So I enabled "Gradle build profiling" in our job.  The results were
> surprising in terms of ratios.
>
> I figured findBugs, checkStyle etc probably added significant times to the
> build.  But I was shocked how much it added.
>
> BTW, you can view these profile reports in {root}/build/reports/profile...
>
> So hibernate-core, overall took 17m22.19s to run for one job.  Of that,
> 12.5 was findBugs!  checkStyle as actually "reasonable" at just under 30s.
> The ratios were similar across all modules.
>
> The aggregatedJavadoc task took a shade over 2m.
>
> Considering that these jobs are run on ever check-in (and eventually it
> would be great to auto-run them against PRs too), plus the fact that we
> aren't even failing the build for the majority of findBug/checkStyle hits I
> think we should define these jobs a little differently.  Its not just the
> time it takes.  Yes we all hate to wait.  But it's also the CI resources
> taken up.
>
> I'm going to put some thought into this after the 5.0 Beta release, but I
> wanted to get some thoughts and feedback in the meantime.  Things to
> consider.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev