1. Stick with only one master. Creating multiple masters seems unnecessary at our size.
2. Don't build jobs on the master...leave that to the slaves. (This seems to be the best practice?)
3. Create two slaves eventually (one is enough for now while we are still performing builds on master too)
4. Configure one slave to use only one executor. Configure the second slave to use multiple executors.
5. Configure certain jobs to run on the appropriate slave (single-executor or multi-executor) depending on the job's needs.
6. Should I be looking at CloudBees or plugins like EC2, Heavy Job, or One-Shot Executor?
I need someone who has "been there, done that" to give me a reality check or alert me to any blindspots before I ask IT to acquire more hardware and configure it. I want to have some confidence this will solve the problem without being overkill.
Any insights appreciated.
In gratitude, I'm happy to answer any Flex questions. :-)
Thanks,
Bruce
Bruce,
If you need to expand the number of executors on your master and prevent the jobs you need to run in sequence from running in parallel, I would look into using the Parameterized Trigger Plugin. You can create a control job to fire off the jobs you want to run one after the other by adding a trigger build step for each of the jobs and selecting the “Block until the triggered projects finish their builds” option. Now the control job will hog one of the executors while each of the triggered jobs is running, so you will need 2 executors to run your sequence of jobs. We have 10 executors open even though we don’t run many jobs and don’t run into any problems.
Hope that helps.
Randy Jackson
Software Build Engineer
Indiana Farm Bureau Insurance
--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/3a038f29-5221-4830-80ae-ca5a70c7ccc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3a038f29-5221-4830-80ae-ca5a70c7ccc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The system load associated with any given build varies extremely widely, so I do not think that it is possible to provide guidelines for how many executors to configure. Some jobs just do a lot of disk i/o, while other use all possible processor threads to build (e.g: make –j steps). It may be possible to build some scheduling heuristics that would put the appropriate jobs on the various slave machines, but it would be insanely complicated and error-prone.
I stopped worrying about it, and just set the number of executors on each machine to one. Nothing runs on the master, as it is busy enough with its normal task load. If that is not efficient, so what? Hardware is cheap in comparison – especially VMs and containerized slaves. Use something like Kubernetes if you want to manage the total Jenkins load on the cluster and spin up more slaves as required.
From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com]
On Behalf Of Bruce Epstein
Sent: July-27-16 14:43
To: Jenkins Users
Subject: Scaling - executors vs slaves
Hi -
--
Good practices to scale, IMO:
* don't build on the master
* Yes. Add agents/slaves, see below.
* Never put more than one executor per agent (slave term now deprecated). Engineering time is far more expensive than having N agents, preventing builds to step over each other's toes.
** We initially used static agents, running in a corporate ESX. And now it's mostly running using a docker swarm cluster, for about 60 hours a day and ~1000 active jobs.
* IMO directly go to two or three agents and not just one. This way you'll maybe avoid (your users) designing builds to depend on a specific machine.
** Corollary: never use node names as labels.
My 2 cents
-- Baptiste