Well, the default setting in the new plugin parent pom is a test-parallelisation of 1C and IIRC the default max heap the the JVM runs on is 512MB. My tests are a bit more hungry for heap than that so I've set the max heap to 1GB per fork (I used to have it on 2GB but our current build slaves couldn't manage that so I needed to tweak my tests a bit) Far from all my tests needs that much but I don't have more fine grained control than that that I know of :)
So a Standard_D3 is well covered for the tests with 4 cores and 14GB of RAM But you wouldn't be able to run more than three docker containers per VM before there is a slight risk that some of my tests will fail in a perfect storm, since the JVM doesn't care about what resource restrictions you put on the containers, it only reads the host values unfortunately. But you should be able to have 6 or 7 containers per VM for those plugins that have the default settings. And I could set my fork count to 0.5C but then, I guess, my tests would take over an hour to run :O And I doubt that I care about the CPU and disk performance at all (within reason), it could be spinning rust and I don't think I would complain :) But I don't see any alternatives for slower CPU without SSD but lots of RAM on the page you provided. /B On Wed, Aug 17, 2016 at 9:47 PM, R. Tyler Croy <[email protected]> wrote: > (replies inline) > > On Wed, 17 Aug 2016, Robert Sandell wrote: > > > What are the specs for the slaves that the plugin builds will be running > > on? I'm asking because I had to do some tweaking of my surefire > parameters > > to make them fit into the slaves (sorry agents) the community plugins are > > currently building on. So an increase in available cores for example > might > > make my build take all available memory ;) > > > The VM sizes that we have access to, generally, are listed here: > <https://azure.microsoft.com/en-us/documentation/articles/ > virtual-machines-windows-sizes/> > > I have also done some cost-analysis and summarized some machine sizes that > we > will likely be using in this document: > <https://github.com/jenkins-infra/azure/blob/master/pricing.adoc> > > I have priced out running a Docker Swarm cluster for full-time rapid use > builds, and those would be Standard D3 machines. > > My /hope/ is that not every single job in ci.jenkins.io attempts to use > the > most expensive VM sizes, but I'm interested in what you all think would be > the > ideal sizing to meet the plugin build/test use-cases. > > > Th time-to-bootstrap comparision between Docker Swarm agents and Azure VMs > for > testing is about 30s vs. 2-5minutes respectively, so consider that for what > plugin builds would need too. > > > I would appreciate any thoughts/suggestions :) > > > Cheers > - R. Tyler Croy > > ------------------------------------------------------ > Code: <https://github.com/rtyler> > Chatter: <https://twitter.com/agentdero> > > % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F > ------------------------------------------------------ > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/20160817194739.GK22427%40blackberry.coupleofllamas.com > . > For more options, visit https://groups.google.com/d/optout. > -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3vVi%3D-UgVXAXBNG9HBoApO_Ebh_rbuoqm8bX-F9XphGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
