[GE users] jobs going to the different queue

Reuti reuti at staff.uni-marburg.de
Tue Aug 7 11:54:33 BST 2007


Am 07.08.2007 um 11:43 schrieb Schenker, Martin:

> Hmm, never happend here up to now.
>
> What would cause this? My understanding was that -q only adds to  
> the specified queue and overrides the sge_request?!?

Not with the -q switch, it will be added and seems to be fixed only  
in 6.0u11 to override it, but not in 6.1 AFAICS.

You can test this by submitting a job with -h to avoid the startup  
and look at the entry "hard_queue_list:". You may find two queues  
mentioned there: the one from the sge_request and the one from the -q  
option.

-- Reuti


> Please shed some light on this!
>
> Cheers, Martin
>
>> -----Original Message-----
>> From: Reuti [mailto:reuti at staff.uni-marburg.de]
>> Sent: 07 August 2007 10:17
>> To: users at gridengine.sunsource.net
>> Subject: Re: [GE users] jobs going to the different queue
>>
>>
>> Hi,
>>
>> Am 07.08.2007 um 09:44 schrieb Schenker, Martin:
>>
>>> I've added the default queue into the
>>>
>>> /SGE/default/common/sge_request
>>>
>>> file like this:
>>>
>>> #
>>> # To have a default queue, that unspecified jobs get put to:
>>> #
>>> # Each user can have an sge_request file,
>>> # or in your case you should edit the global one in
>>> # SGE_ROOT/default/common/sge_request
>>> #
>>> # Put in a line with -q  <your default queue spec>
>>>   -q main.q
>>> #
>>>
>>> This results in all jobs NOT having the "-q" prefix to be
>> scheduled
>>> there. My other queue has to be
>>>
>>> targeted with "-q second.q"
>>
>> yes, but this might lead to the situation, that jobs having -q
>> second.q will still go to the main.q. This might or might not be
>> desirable  - depends.
>>
>> -- Reuti
>>
>>
>>> Best, Martin
>>>
>>>> -----Original Message-----
>>>> From: Dan.Templeton at Sun.COM [mailto:Dan.Templeton at Sun.COM]
>>>> Sent: 06 August 2007 23:16
>>>> To: users at gridengine.sunsource.net
>>>> Subject: Re: [GE users] jobs going to the different queue
>>>>
>>>>
>>>> There are a variety of possible solutions to the problem.
>>>> One solution
>>>> would be to use forced complexes.  You could define three boolean
>>>> complexes, queue1, queue2, and queue3, and make queue2 and
>> queue3 be
>>>> forced.  You'd then assign each queue the appropriate
>>>> complex.  When a
>>>> user requests -l queue<n>, his job will go to that queue.  If
>>>> the user
>>>> does not request a resource, then the only queue that will
>> accept the
>>>> job is queue 1, because the queue1 complex is the only one
>> that's not
>>>> forced.
>>>>
>>>> Another option would be to use queue sequence numbers, but
>> that would
>>>> not prevent jobs from running in queue 2 or queue 3.  It would only
>>>> ensure that jobs that don't request a queue would get sent to
>>>> queue 1 if
>>>> it's available.  If queue 1 is full, then jobs could go to
>> queue 2 or
>>>> queue 3.
>>>>
>>>> Daniel
>>>>
>>>> A listner wrote:
>>>>> Hi,
>>>>> In my cluster I have three queues  say A, B and C . I do
>>>> not want any
>>>>> one run the job I want if user does not specify " -q
>>>> queue_name"  then
>>>>> jopb should go to the queue "A" but not to the B and C.
>> Where do I
>>>>> have to configure it? Please help.
>>>>>
>>>>> -S
>>>>>
>>>>>
>>>> --------------------------------------------------------------
>>>> ----------
>>>>> Shape Yahoo! in your own image. Join our Network Research
>>>> Panel today!
>>>>>
>>>> <http://us.rd.yahoo.com/evt=48517/*http://surveylink.yahoo.com
>>> /gmrs/yahoo_panel_invite.asp?a=7>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>

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