Hi, Am 16.03.2016 um 19:20 schrieb Jackson, Gary L.:
> I've painted myself in to a corner with all.q. Now I have many long-running > jobs in that queue and no way to run shorter testing and debugging jobs. Do the jobs request a runtime? Just create an additional queue with an upper limit for h_rt. SGE will schedules only jobs to this queue which will fit into this constraint. Note that slots per exechost instance need to be restricted not to bypass the installed core count. This can be achieved by attaching the "complex_values slots=16" or alike to each exechost configuration. As the upper limit per queue is still to be defined in the queue configuration, you can also limit the number of slots independent between short.q and all.q to allow only a subset of cores for short jobs or vice versa. If you lower the slot count in all.q, the running jobs will still continue and at one point make room for short jobs. And/or you could in addition also create a special forced boolean complex with a high urgency, so that short jobs will be handled preferred and this complex need to be requested by the jobs which want to go to the short.q and it needs to be attached to short.q. > How do I carve a separate queue out of my current resources without > disrupting either running or currently queued jobs? Existing jobs currently > running on hosts allocated to a new queue should run to completion. All changes in SGE in the general, scheduler, queue or exechost configuration are live and won't disrupt any running jobs. You can even reboot the qmaster and won't lose any running or pending jobs. -- Reuti _______________________________________________ SGE-discuss mailing list [email protected] https://arc.liv.ac.uk/mailman/listinfo/sge-discuss
