56) MaxJobs: Dynamic Use of Multi-Core

That leaves two cores and some memory available for whatever it is that Windows does when you are not looking (scans, updates, backups) and for the other things that you want to do while you are waiting for the results, like e-mail and model building.  If the models I am running are very large  - a lot of periods / locations / PSIs / crudes / MIP – so that it needs a lot of memory, I go down to 5 or even 4. 

The max job setting operates dynamically as well, so you can change it even when you have a lot of runs going.  For example, if I have jobs queued up when I am going to lunch,  I push the number up via the File Settings dialogue in Queue Manager.

 

 

It will start more jobs until running the new maximum.  When I am back at my desk, if I reduce it again, it won’t start another job until enough have finished that another one won’t go over the new limit.   (For more information about using the other settings see Note #11 Effective Use of Spooling.)

I also use the maximum jobs setting dynamically to “jump the queue”.   If I am working, for example, on model development while some other multi-case job  - like a multi-start - is already running, I reduce the maximum jobs to 5.  Whenever I want to check my model– which I, of course, I do every time I make a significant change to ensure I haven’t broken anything - I submit a run and use the blue up-arrow in the Queue Manager menu bar (see above - the one with the bar at the top) to push it to the top of the list so it is the next job that will run.   Set the job to ASAP, then change the Max Jobs to 6, so it starts.  So the background jobs don’t jump in and take the spare core when the test run is finished, change max jobs back down to 5 before you go put the kettle on, or at least stand up and have a stretch.