Am 22.08.2011 um 14:26 schrieb Schmidt U.:
> On 08/22/2011 01:55 PM, Reuti wrote:
>> Am 22.08.2011 um 13:13 schrieb Schmidt U.:
>>
>>> Dear all,
>>> is there a way to define slot quotas dynamically ? By default I set the RQS
>>> to
>>> {
>>> name slot_per_us
>>> description "slot limitation"
>>> enabled TRUE
>>> limit users {*} to slots=200
>>> }
>>> But sometimes users have a huge amount of short jobs, because of that I
>>> think about a solution similar like "slot * walltime"
>>> Can I add a kind of variable instead of fixed number ?
>> Dynamic limits are only working on a per host basis (man
>> sge_resource_quota), although it was a long term goal to implement any
>> combination for them I think.
>>
>> But even then walltime (unit TIME) and slot (unit INT) can't be multiplied
>> in a meaningful way.
>>
>> You want to allow for example: 1 job with 24 hrs run time, or 24 jobs with 1
>> hr run time?
> 24 jobs with 1 hr run time.
>> Would it help to make an RQS as a combination of user and queue (i.e. some
>> kind of "short-queue" with a h_rt limit that judges the jobs therein as
>> being short)?
> By now, the users must not yet set a h_rt obligatory in our configuration.
> We have a short queue for users who want to have advantage of a short short
> queue (h_rt=2hr). So I should define default h_rt and force the users to add
> h_rt in the scripts ? But then I have still a fixed number of hosts in the
> short queue.
> On the other hand, would it better then not to use the RQS "slots per user"
> and therefore only fairshare policy weighted to h_rt ?
There is also the option to have a cron-job running, which will adjust the slot
count of an RQS where you have one line per user / per queue. You could check
what they have already running in the cluster and allow a certain number of
short jobs depending on the number of jobs in the long queue.
A functional share has no memory and can't look into the future, that some jobs
are supposed to run longer than the defined short jobs.
In some was I think you are looking for a share-tree policy working in the
opposite way: i.e. looking into the future and depending on the job-mix of an
user (assuming the h_rt or short/long-job-queue is in some way accurate) decide
what is allowed to start for a user.
-- Reuti
> buudo
>>
>> --- Reuti
>>
>>
>>> buudo
>>>
>>> _______________________________________________
>>> users mailing list
>>> [email protected]
>>> https://gridengine.org/mailman/listinfo/users
>
>
> --
> Udo Schmidt
>
> Max-Planck-Institut für Mikrostrukturphysik
> Weinberg 2, 06120 Halle (Saale), Germany http://www.mpi-halle.de/~theory
> Phone: +49 345 5582541 Fax: +49 345 5582765 Email: [email protected]
>
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
