On 2/23/12 2:06 AM, Mickael Istria wrote:
Hi Denis, Winston, all,
Right. So I propose that the 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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|