Should be no surprise that you're certainly not the first bringing up this request, Ed ;-)

The feature enhancement therefore is on our roadmap already. Thanks for the suggestion, though.

Cheers,

Fritz

Ed Lauzier schrieb:
Hi,

For reference - here is what I have configured and tested:  ( Until this gets implemented - wink, wink, Univa....)

ex submission:  ( also works for job arrays....of course )

qsub -t 1-100 -cwd -V -b y -l slots10=10 sleep 120

This will provide the user the ability to limit how many jobs they want to run using predrfined
limits...

complex definitions....

slots10             s10        INT       <=      YES         YES        0        0
slots100            s100       INT       <=      YES         YES        0        0
slots20             s20        INT       <=      YES         YES        0        0
slots50             s50        INT       <=      YES         YES        0        0

global host def:

hostname              global
load_scaling          NONE
complex_values        slots10=100000,slots100=100000, \
                      slots20=100000,slots50=100000
load_values           NONE
processors            0
user_lists            NONE
xuser_lists           NONE
projects              NONE
xprojects             NONE
usage_scaling         NONE
report_variables      NONE


resource quota sets:

{
   name         per_user_10_job_limit
   description  allows user to select slot limit to throttle number of running \
   jobs
   enabled      TRUE
   limit        users {*} to slots10=10
}
{
   name         per_user_20_job_limit
   description  allows user to select slot limit to throttle number of running \
   jobs
   enabled      TRUE
   limit        users {*} to slots20=20
}
{
   name         per_user_50_job_limit
   description  allows user to select slot limit to throttle number of running \
   jobs
   enabled      TRUE
   limit        users {*} to slots50=50
}
{
   name         per_user_100_job_limit
   description  allows user to select slot limit to throttle number of running \
   jobs
   enabled      TRUE
   limit        users {*} to slots100=100
}


Thanks,

Ed


-----Original Message-----
From: Reuti [mailto:[email protected]]
Sent: Friday, June 14, 2013 10:52 AM
To: 'Ed Lauzier'
Cc: [email protected]
Subject: Re: [gridengine users] per-user limit for number of running jobs on the cluster set by the user

Hi, Am 14.06.2013 um 14:44 schrieb Ed Lauzier:
> In ge, there is the ability to have the end-user set the number of running
> jobs/tasks for a job array submission:
>
> ex:
>
> qsub -t 1-1000 -tc 20 ...
>
> This allows users to play "nice" with other users especially for jobs
> that are long-running....or under certain coonditions where running
> too many jobs of a certain application may impact other users
> ability to run jobs of the same app.
>
> For normal jobs ( not job arrays ) is there a way for a particular user to
> limit the number of his running jobs? Tokens can be used, but I was
> hoping that there may be a submission parameter that would allow
> users to do this themselves w/o having to set up a token-based limiting
> method.... Only as admin you can set this up by an RQS, not as a normal user.
What could be done to help the users: they could specify the intended number in a file like "~/.sge_jobs".
A cronjob could read all the values and modify the RQS for this user.
The syntax is : $ qconf -mattr resource_quota limit slots=50 general/reuti for a
lines: name general limit name reuti users reuti to slots=50
Resp. doing it on a per job bases with a complex "jobs" consumable as per JOB.
-- Reuti
> Thanks,
>
> Ed
>
> _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users

--

UnivaFritz Ferstl | CTO and Business Development, EMEA
Univa Corporation | The Data Center Optimization Company
E-Mail: [email protected] | Phone: +49.9471.200.195 | Mobile: +49.170.819.7390


Where Grid Engine lives



_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users

Reply via email to