Am 12.03.2012 um 15:23 schrieb Robert Hutton:
> On 12/03/12 12:03, Reuti wrote:
>> Am 12.03.2012 um 12:57 schrieb Robert Hutton:
>>> Is there a way to attach prio=false by default to any job that doesn't
>>> specify a value for it? I note this from the sge_complex(5) man page:
>>>
>>>> default
>>>> Meaningful only for consumable complex attributes (see consumable
>>>> parameter above).
>>>
>>> I've tried requestable FORCED, but this doesn't seem to change the
>>> behaviour. I suspect that I'm making a pretty obvious mistake here... ;)
>>
>> FORCED should exactly do what you want.
>>
>> What behavior you observe in detail? Long jobs not requesting "priority"
>> ending up in shortrun.q?
>
> The problem situation is with many short jobs on an unloaded cluster:
>
> With:
> - number of jobs > number of cores offered by the cluster
> - "-l priority" NOT specified to qsub
> - a runtime < 2 hours (which is the limit for the fastrun.q)
> - complex configuration includes:
>
> #name shortcut type relop requestable consumable default urgency
> #----------------------------------------------------------------------
> priority prio BOOL == YES NO 0 0
>
>
> Number of cores available is 140.
>
> Command is:
> for run in {1..200} ; do qsub -cwd -S /bin/bash -l
> h_vmem=1G,virtual_free=100M,h_rt=0:1:0 sleep.sh ; done
>
> sleep.sh just sleeps for 30 seconds.
>
> Behaviour is that both the shortrun.q and longrun.q fill with jobs, with
> longrun.q having as many jobs in state "S" as there are slots in the
> queue instance of shortrun.q on that host (due to slotwise preemption).
Yes, correct behavior.
> With everything the same as above, but with "priority" requestable set
> to FORCED:
>
> Behaviour is that all jobs just sit in the "qw" state and the scheduling
> info shows:
Yes, as you need to request it in the `qsub` command.
> (no project) does not have the correct project to run in cluster queue
> "bigMem.q"
> does not request 'forced' resource "priority" of queue instance
> [email protected]
> does not request 'forced' resource "priority" of queue instance
> [email protected]
> [snipped: same for the rest of the queue instances for longrun.q and
> shortrun.q]
>
>
> Queues have complex values:
>
> longrun.q:
> complex_values h_vmem=48G,virtual_free=47G,priority=false
As it's FORCED, it shouldn't be specified for the longrun.q.
> shortrun.q:
> complex_values virtual_free=12G,h_vmem=13G,priority=TRUE
>
>
> The behaviour that I find confusing is with requestable set to YES, jobs
> still get sent to shortrun.q despite not having "-l priority=true" given
> to qsub.
If you don't specify it, it means: I don't care. So you can end up in a queue
(or on an exechost) having this feature or not.
> So I guess perhaps that it's not possible to set up a default value for
> my "priority" boolean complex attribute without forcing users to always
> specify -l priority=true or -l priority=false to qsub. Perhaps I could
> set it to FORCED, and put "-l priority=false" into
> .../default/common/sge_request file to make it the default?
No, if it's set to false only jobs requesting it can run in the shortrun.q.
=> long jobs: like usual
=> short jobs: need "-l priority" as shortcut to "-l priority=TRUE" to end up
in shortun.q.
For the latter you could setup a JSV, which attaches this complex in a case the
runtime is below a certain value.
-- Reuti
> Thanks again,
>
> Rob
>
> --
> Robert Hutton
> Senior Systems and Database Administrator
> Centre for Genomics and Global Health <http://cggh.org>
> The Wellcome Trust Centre for Human Genetics
> Roosevelt Drive
> Oxford
> OX3 7BN
> United Kingdom
> Tel: +44 (0)1865 287721
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
