[GE users] Running 1, 2, 3, or 4 jobs on a host with 4 slots

Reuti 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. ]

Hi James,

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
> it
> 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
> subordination.
> 
> 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
> this
> node. So only this particular que, once it was used, could ever fill that
> particular node up to 3 total slots used.

correct!

> 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
> experience.

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
> consider
> filling in the rest of the 3 slots, one at a time, ....... or would that
> let
> 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
> use
> 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 
achieve.

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 
job.

> If these numbers were left blank, then the total slots would have to be
> used
> 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
> ever
> 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 
blank.

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 mailing list