As Gurobi is computationally intensive, by default it will try and use as many cores as possible. When solving multiple models on the same machine at the same time, care must be taken as to not over-subscribe the cores of the CPU as this will result in slower and variable run times. For example, if you have an 8 core machine and run 4 jobs and do not limit the number of threads of a job, then those 4 jobs will likely end up sharing the same cores, which we are trying to avoid. But if you limit
Threads = 2 for each of the 4 jobs, then the OS will likely allocate the jobs across different pairs of cores.
So to summarise:
Threadsparameter tells Gurobi the maximum number of threads to use when solving a model -- the OS then allocates the threads to processor cores.
JobLimitparameter tells the Compute Server to begin queuing jobs after the specified number of jobs are running.
- If the number of threads used by jobs simultaneously running on the same Compute Server exceeds the number of cores of the machine, then this will significantly slow the solve time due to over-subscribing the cores.
To determine appropriate values for
JobLimit you need to test your models to discover the best number of cores to solve them. Some models need only one core. Some benefit from 32 cores. Testing will tell you this.
You would never want to set the job limit to a very large number such as 100 unless you have a 100-core machine and you limit Threads to 1. Otherwise, this will very likely make all of the jobs take longer than they would have if you had solved them in sequence.