[GE users] Running 1, 2, 3, or 4 jobs on a host with 4 slots
reuti at staff.uni-marburg.de
Thu Mar 17 19:24:47 GMT 2005
[ The following text is in the "ISO-8859-1" character set. ]
[ Your display is set for the "ISO-8859-10" character set. ]
[ Some special characters may be displayed incorrectly. ]
Quoting "Marconnet, James E Mr /Computer Sciences Corporation"
<james.marconnet at smdc.army.mil>:
> Thanks Reuti! This is making more sense to me, slowly as I consider your
> suggestion and read and re-read the documentation.
> I had not caught from my earlier read of the documentation that this
> subordination of ques worked on a node by node basis. I was thinking that
> subordinated an entire que at a time (for all node instances), not a single
> que instance.
> But I'm still struggling a little on the exact number to put in to trigger
> You suggested: max2=1,max3=1,max4=1 (see below)
> As I understand it, with the number set to 1, submitting 1 job to a que
> allowing 3 slots per node would then immediately subordinate all the other
> ques specified individually after just one (1) instance (run) starts on
> node. So only this particular que, once it was used, could ever fill that
> particular node up to 3 total slots used.
> Then it seems that if just 1 job finished out of 1, 2, or 3 jobs running on
> that node, that all the ques would be un-subordinated, leaving things wide
> open again? Seemingly then with just 1 or 2 jobs running, some jobs
> submitted to a que that allowed 50 slots could quickly oversubscribe this
> node way past the 3 jobs/node that these particular jobs were expecting to
No - the setup is "=" in syntax, but the executed relation is always "used
slots >= subordinate value". To open the other queues again, all jobs must end
in the just used queue.
> Another possibility, could the number be set to 3 to let other ques
> filling in the rest of the 3 slots, one at a time, ....... or would that
> them go ahead and fill it beyond 3 slots because this particular
> subordination "rule/setting" would not ever be re-considered when assigning
> the next job from another que? I'm thinking that the only safe number to
> is 1, as you suggested.
Yes, this could happen - therefore always one in the setup. If I got you
correctly, you would end up with 3 jobs running in the 4 job queue, 2 in the 3
job queue and 1 in the 2 job queue. This is not the result you wanted to
I was also thinking of the possibility to have 2 jobs of type max4 and one with
max3 - this would fit with your intended setup, but I didn't found a way to put
it in a SGE setup. What comes close would be just having one queue and the
introduction of a consumable complex "cpu_usage" which is attached to each node
with a value of 12.
Then you have to submit the job with -l cpu_usage=
12 = one job per node
6 = two jobs
4 = three jobs
3 = four jobs
But 6 + 3 + 3 would also be possible, which would violate the rule for the max2
> If these numbers were left blank, then the total slots would have to be
> up (3 in this case, by this particular que - or perhaps more if partially
> filled by this que and then filled more by another less-restrictive que)
> before the subordinated que would be suspended. Would that make sense in my
> case? I don't think so. In what sort of instance would leaving it blank
> make sense?
Having a two CPU node, you may allow someone to use one slot in a hobby-queue
(with one slot) when there is no demand for use it in production. When one
production like job comes in (2 slot in this queue) - nothing happens. But when
the second production job comes in, the hobby-queue is suspsended.
And having only one CPU nodes, it's just a short cut that you can leave it
Regards - Reuti
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net
More information about the gridengine-users