Are the 2 groups of nodes defined as queues? If so, limit on queues
may work for you:
limit queues XXX to slots=16
On Wed, Sep 23, 2015 at 10:27 AM, Simon Andrews
<simon.andr...@babraham.ac.uk> wrote:
>
>
> On 23/09/2015 15:20, "Jesse Becker" <becke...@mail.nih.gov> wrote:
>
>>On Wed, Sep 23, 2015 at 10:56:21AM +0000, Simon Andrews wrote:
>>>I?m trying to use RQS to limit the total number of slots which users can
>>>take up on our cluster. This is slightly complicated by the hosts being
>>>split into two groups, one for batch jobs (@compute) and one for
>>>interactive jobs (@interactive). The idea would be that I?d limit the
>>>total slots taken up by a user on the @compute set, but not restrict
>>>@interactive.
>>>
>>>The RQS rule I?m using is:
>>>
>>>{
>>> name per_user_slot_limit
>>> description "limit the number of slots per user"
>>> enabled TRUE
>>> limit users {*} hosts {@compute} to slots=16
>>>}
>>>
>>>However I don?t think this is generating the right effect. I think what
>>>this is doing is saying that the limit of 16 slots applies on each of
>>>the individual members of @compute, and not on the sum of the slots
>>>across all of @compute.
>>
>>I'm guessing that using:
>>
>> limit users {*} hosts @compute to slots=16
>>
>>doesn't work?
>
> I think that¹s functionally the same as my previous version, the brackets
> aren¹t strictly required in this case.
>
> I think I have a work round which is:
>
> {
> name per_user_slot_limit
> description "limit the number of slots per user"
> enabled TRUE
> limit users {*} hosts {@interactive} to slots=16
> limit users {*} to slots=16
> }
>
> ..where the @interactive limit is a no-op since that¹s as many cores as
> any of the interactive hosts have. It works because the interactive jobs
> hit the first rule, match and then don¹t proceed to the more general rule.
> I think it¹s working, but it seems somewhat inelegant and I suspect
> there¹s a better way to do this.
>
>
> Simon.
>
>
>
> The Babraham Institute, Babraham Research Campus, Cambridge CB22 3AT
> Registered Charity No. 1053902.
> The information transmitted in this email is directed only to the addressee.
> If you received this in error, please contact the sender and delete this
> email from your system. The contents of this e-mail are the views of the
> sender and do not necessarily represent the views of the Babraham Institute.
> Full conditions at: www.babraham.ac.uk<http://www.babraham.ac.uk/terms>
>
> _______________________________________________
> users mailing list
> users@gridengine.org
> https://gridengine.org/mailman/listinfo/users
--
Best,
Feng
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
