On 2/23/12 2:06 AM, Mickael Istria wrote:
Hi Denis, Winston, all,
Right. So I propose that the tycho-gmp.gmf.tooling
<https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/job/tycho-gmp.gmf.tooling>
job be moved over to our Sandbox so that its memory consumption does
not impact our Hudson instance. Any objections?
How much trouble does this cause to other jobs? Is this job the only
responsible for Hudson being slow? Would removing from Hudson save the
world?
Certainly not. As I mentioned earlier I'm trying to knock down large
memory consumers. The over all memory occupied by this job is lot less
than memory occupied by hudson-test-harness which I fixed already. I'm
just looking to see if I can do something in this job also to reduce
memory, but that alone is not enough.
If yes, then I think it is fair to move it TEMPORARLY to the sandbox
while the issue is not fixed. But I'd be OK with that just if someone
can promise to the GMF Tooling team that the issue (which is in GMF
build? in GMF job? in Maven? in Hudson?) will be fixed in a short
delay, otherwise the CI job for GMF Tooling will be forever in a
sandbox, it'd have a bad effect on the project. Also, be sure that if
GMF Tooling job is moved to sandbox, the same problem will happen on
sandbox...
If no, then it seems that the job does not cause real trouble, then
let's keep it as it and keep on enjoying life while Hudson folks
improve the memory consumption.
Is there any benefit in blaming this job and moving it to sandbox?
No it is not the cause of trouble, I don't recommend to move it. It
helps in a small way if we can fix what ever in this job takes up memory
like I did in hudson-test-harness. But that is not going to make the
whole issue go away.
Winston,
Correct me if I'm wrong, but since the build happens in a forked
process in Hudson, it does not consume memory by itself. Then the
problem is clearly in Hudson or one of its plugins, isn't it? So the
Maven/Tycho build by itself is not the culprit. If the memory is
consumed by Hudson JVM, then the issue in is Hudson.
Is there something we could change in configuration of the job to make
it consume less memory?
About the tests, GMF-Tooling has 431 tests, I am not really sure. Some
other projects probably have more tests on this Hudson instance and
don't have the same problem. But maybe the content of test reports is
bigger in GMF Tooling (more execution traces maybe?) causing this huge
memory consumption.
Any help is appreciated. You can get me on Skype: mickael.istria
After the build is done, Hudson keeps some of the build artifacts such
as JUNit or maven metadata info. Since hudson keeps all the builds of
all joba, this bloats up the memory. The immediate solution is reduce
the foot print of these build artifacts, if we can. Long term term
solution is fix Hudson not to keep all the builds in memory
- Winston
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
