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 -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp More details can be found in the doc at https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-WriteyourownscripttolaunchJenkinsslaves. --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.
