Thank you Rob. Very very useful. I'll do my homework and then I may be back here. Best regards.
On 13 Giu, 16:56, "Mandeville, Rob" <rmandevi...@litle.com> wrote: > The master runs in the same JVM as the server. I see only two reasons to use > the master: > 1: When starting out, just seeing what Jenkins can do > 2: When you need direct access to the server (for instance, I have some > Scriptler Groovy jobs that directly access Jenkins' data structures without > using the HTTP API) > > I recommend using slave nodes whenever possible, and limiting each job to a > certain label to keep it off of the master. > If there is some sort of firewall between Jenkins and the number crunching > cluster, server and slave machine, there are a couple of ways to handle this. > 1: If you can use ssh to get to the number crunching cluster, you can build > the slave and tell Jenkins to launch it via SSH. It would ssh over to the > target system, and use the SSH connection for I/O. There is an SSH Slaves > plugin to make this a lot easier. > 2: If you can see the Jenkins server from the cluster using a client like > wget or curl (that is, if port 8080 is open), you can set up the cluster to > launch the client and connect. The syntax is of the form: > > $ java -jar slave.jar > -jnlpUrlhttp://yourserver:port/computer/slave-name/slave-agent.jnlp > > More details can be found in the doc > athttps://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distri.... > > --Rob > > > > > > > > -----Original Message----- > From: jenkinsci-users@googlegroups.com > [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Nunni > Sent: Wednesday, June 13, 2012 9:53 AM > To: Jenkins Users > Subject: Re: build processes priority? > > On 13 Giu, 15:35, "Mandeville, Rob" <rmandevi...@litle.com> wrote: > > Jenkins doesn't recognize "nice" because that's a Unix-only feature; I'm > > not sure if there is an equivalent Windows feature. Of course, if your > > steps are shells, you can tell those to nice themselves. You could also > > "nice" your slave nodes when you launch them, if you do so by script. > > Niceness is inherited, so a slave node running at a given nice level will > > run jobs at that same nice level. > > Jenkins itself tends to be rather light on the CPU, but it takes up > > networking resources and disk I/O because it receives output from the jobs > > it runs and logs them. Idle slaves are light, and a slave in use only adds > > a little overhead, mostly the network traffic of sending logs back to the > > server. > > When you configure a job, it has an "Execute concurrent builds if > > necessary" flag. With that turned on, you can run more than one in > > parallel. > > If you want some jobs to be "nicer" than others on the same machine, you > > can use the Jenkins Heavy Job Plugin. Basically, while a normal job takes > > up one executor (a node can have one or more executors, each capable of > > running a job), a heavy job can take up multiple ones. So if you have job > > A (an easy one) and job B (a resource hog), you can tell Jenkins that Job B > > has a "weight" of (say) 3. If you had a node with four executors, this > > would mean: > > 1: Job B would not run until there are three free executors, so it > > would wait until no more than one copy of job A was running > > 2: Job B would take up three executors, so when it was running, Jenkins > > would put no more than one copy of job A on that node, and not another > > version of job B (to run two job B's on the same node, you'd need at least > > six executors). > > > Hope this helps, > > > --Rob > > Hi Rob. > Thank you for your exaustive reply. Now I have a better idea of how things > work in jenkins. I have a couple of questions. > 1) Do you know if the master executor will do the builds in a separate > process or inside the same process of the webapp? > 2) I just realized we have a number crunching cluster here on a different > subnet.. what if I put a few executor there? What about the communication > between jenkins the executors? Ports, protocol, ecc.. > > Thank you again! > > The information in this message is for the intended recipient(s) only and may > be the proprietary and/or confidential property of Litle & Co., LLC, and thus > protected from disclosure. If you are not the intended recipient(s), or an > employee or agent responsible for delivering this message to the intended > recipient, you are hereby notified that any use, dissemination, distribution > or copying of this communication is prohibited. If you have received this > communication in error, please notify Litle & Co. immediately by replying to > this message and then promptly deleting it and your reply permanently from > your computer.
