[GE users] how to restrict max 2 jobs per user/user group

Sangamesh B forum.san at gmail.com
Mon Nov 17 04:28:40 GMT 2008


On Sat, Nov 15, 2008 at 7:10 PM, reuti <reuti at staff.uni-marburg.de> wrote:
> Hi,
>
> Am 14.11.2008 um 16:56 schrieb Sangamesh B:
>
>> Hello SGE users,
>>
>>       In a cluster, installed with Rocks 4.2.1 and SGE 6.0U8,
>> following configuration is required:
>>
>> Two kinds of users:    External & Internal
>>
>> Restrictions for External users:
>>
>> Not more than two jobs are allowed and each job can take max 16 slots.
>> And each job has a restriction of max 72 hours as run time.
>>
>> No restriction for Internal Users.
>>
>> For this I,
>>
>> Created two usersets: EXTERNAL & INTERNAL
>> Created a queue external.q with 8 hosts (dual core dual processor) -
>> total 32 slots
>> Set h_rt to 72 hours in external.q
>>
>> But not getting how to set only <=2 jobs should run?
>
> it's not possible for now to limit the number of jobs, although it's
> an RFE for a future release of SGE. For now you can limit only the
> slots in 6.1/6.2 by an RQS. For 6.0 you are stuck with a workaround
> like I posted two days ago:
>
> http://gridengine.sunsource.net/ds/viewMessage.do?
> dsForumId=38&dsMessageId=88707
>
> which even doesn't apply to your case.
Thanks for your valuable suggestion.

Referring, your post achieved restricted number of jobs to 2.

1). Created a complex with value 2 as follows:
# qconf -sc
#name               shortcut   type        relop requestable
consumable default  urgency
#----------------------------------------------------------------------------------------
external            ext        INT         <=    YES         YES
 2        0

2). In each external user's home directory created .sge_request with
the following content:

-l ext=1

A queue external.q with 8 hosts - total 32 slots.

Added "ext" under complex_values entry, as follows.

complex_values        external=2

Still this setup is not complete as the job may take more than 16 slots.

>
>> Also this configuration is not a feasible solution in the following
>> cases:
>>
>> As internal users are "xusers" for this queue,
>
> BTW: having a user_lists attached to a queue, unlisted users are
> automatically excluded. There is no need to mention them also in the
> xuser_lists entry.
>
>
>> then some slots out of
>> 32 may remain unused.
>> To overcome this, if internal users are allowed, then external users
>> jobs may stay in waiting state.
>>
>> Can someone on the list suggest, how to
>>
>> 1. allow only two jobs for external user group
>> 2. Internal users jobs should be allowed to run in external.q, if
>> slots = (32 - number of slots occupied 2 external users jobs) is
>> greater than 0
>
> Even it it would be possbile to set it up right now, I'm not sure
> whether it's the best approach. Imagine the external users have two
> jobs running and occuyping 8 slots in total. So you would like to
> allow internal users to use the remaining 24 slots - unfortunately
> these are really long jobs. After some while the two external jobs
> end and now they want to run 2 jobs with 16 slots each - so using the
> granted number of 32 slots. They have to wait. (If you grant them 32
> slots, you could also state that it's up them, how to use these for a
> mixture of serial and parallel jobs.)
>
> For a hard-coded setup of the nodes (which you did already as you
> mentioned), you could also tell the internal user to run jobs on the
> @internal_hgrp nodes, and if they decide to use @external_hgrp, they
> can do so if slots are free, but their jobs might get suspended when
Is that with the existing setup? How the jobs get suspended?
> the external users decide to run a job there.
>
> Is this feasible?
I think its very difficult to get the exact requirement.
>
> -- Reuti
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=88805
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=88852

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list