incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <lsim...@jicarilla.org>
Subject resource usage
Date Thu, 08 Jul 2004 09:48:43 GMT
Hi gang!

Noel J. Bergman wrote:
> I would also like the GUMP folks to take a close look at their needs.
> Specifically, I have just made arrangements that they ought to be able to
> get a copy of VMware GX for brutus.  That will allow them to clone system
> configurations from a master disk image (virtual disk file) whenever they
> want to start afresh with a clean system.  They could install whichever
> operating system(s) they want in the virtual machines, play around with
> configurations, etc., and not worry about problems.  If a project ended up
> with a requirement came up to do some testing with MS.NET and Mono, they
> could do that, too.  I know that they've looked at resources before, but
> they weren't accounting for disk images and the memory overhead.  They may
> not need to add anything; I'm just suggesting that they check based upon
> this possibility.

VMware would be nice (though I have no experience with GX, I imagine its 
better than the consumer stuff ;).

I've been looking into our current resource consumption. Remember, we 
used to run gump on a duron ghz PC, and before that it was a pentium II...

1) processor

when there's no gump run, it throts along at 5% or less. During gump 
runs it mostly takes about 25% or so (meaning the bottleneck is 
elsewhere, probably disk), except during merge steps and things like xml 
transformation, when it peaks out briefly (ie a second or two, never 
more) at a 100%.

I think we could run two gump builds (like the "main" one and an 
"experimental" one) concurrently in seperate VMs and still have quite 
acceptable performance, even considering the overhead.

2) memory

We have quite a bit of redundant memory. Gump itself eats about 50mb; 
the most intensive java compilation stuff (really big javadoc trees 
built using maven in a multiproject setup are an example) never takes 
more than a 1/2GB and that's a rare exception I've seen only once, and 
not on brutus so far. So the swap space is unused (we have 2GB of memory).

I think if we run two gump builds concurrently in seperate VMs we would 
still not need to resort to swap space.

3) disk

Of the 60Gb or so we have we're using about 15GB, and this is with 
several seperate gump trees, and including the OS. A single gump tree is 
about 4.5GB, with about 125MB of output every night.

Even with the overhead of a GSX install, I guess we have enough space 
for a small image (the cvs checkouts 'n stuff don't need to be on the 
"master image"), two seperate VMs running at the same time, and /plenty/ 
of space to spare for gump to grow.

So we're fine wrt space. I think disk speed is our bottleneck right now, 
and if we'd consider upgrading anything (which I don't think is 
neccessary), it's the main thing to attack. My guess is that the same 
would be true for a dedicated nightly build machine.


cheers,


- LSD

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message