[gridengine users] suggestions on setting up queues

Ed Lauzier elauzier2 at perlstar.com
Sat Jan 17 22:49:48 UTC 2015

 The perl JSV is a good way to enforce defaults based on projects.
With resource quota sets, you have the most flexibility.

Watch out though....for resource quotas per host or host groups with
a high throughput of jobs, you need a master that has at least 4 processors....

The calculations that are required by the scheduler for each scheduling cycle
need resources, esp with resource quota sets per host enabled....

Also, avoid using the bash JSV. It is too slow. Perl JSV works great, but
make sure that you keep it simple....

The resource quota sets for max slots per host also allows you to share hosts nicely between queues,
if you need more than one queue...

Complex boolean resource tags work great also for job steering to the right
type of hosts...

Fairshare for lots of very long running jobs is almost impossible to do properly.
So, limiting the number of slots used for very long running jobs to say max 60%
of total slots may work out best...

Hope this helps...


-----Original Message-----
From: Chris Dagdigian [mailto:dag at sonsorol.org]
Sent: Friday, January 16, 2015 03:51 PM
To: 'Stephen Spencer'
Cc: users at gridengine.org
Subject: Re: [gridengine users] suggestions on setting up queues

Queues are just a piece of the puzzle when it comes to handling resource allocation on a multi user system, what (if any) scheduling policies and resource quotas are you currently using?That said you are using the queue methods in a good way. There are certain things that can only be really done on a per-queue basis and top of the list would be ACL protection and the ability to impose hard or soft wallclock limits.A fairshare-by-user policy with the queue structure you set up would be a decent starting point from which you can gather more data and user feedback.Thoughts - resource quota would perfectly handle the "only N jobs per user can run in the long-job.q cluster queue ..." - I've had little success putting wallclock limits on interactive queues; there are legit business/scientific reasons in many cases for a long running interactive session. You might want to poll the users or collect data on this. In a few different environments I've had decent success by leaving interactive queue slots unrestricted but putting a resource quota around how many slots a single user can consume. It's also pretty easy to set up tools that would allow you to dynamically adjust the size/count of the interactive slot pool to account for changing demand - it's particularly easy when used with SGE hostgroup objects.My $.02> Stephen Spencer > January 16, 2015 at 2:50 PM> Good morning.>> With the number of users on our clusters growing, it's becoming less > realistic to say "play fair 'cause you're not the only user of the > cluster.">> I'm looking for suggestions on setting up queues, both the "why" and > "how," that will allow more of our users access to the cluster.>> What I'm thinking of is a multi-queue approach:>> * some limited number of "interactive" slots (and they'd be> time-limited)> * a queue for jobs with short time duration - the "express" queue> * a queue for jobs that will run longer... but only so many of these> per user>> Any and all suggestions are welcome.>> Thank you!>> Best,> -- > Stephen Spencer> spencer at cs.washington.edu > _______________________________________________> users mailing list> users at gridengine.org> https://gridengine.org/mailman/listinfo/users_______________________________________________users mailing listusers at gridengine.orghttps://gridengine.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gridengine.org/pipermail/users/attachments/20150117/85b01d03/attachment.html>

More information about the users mailing list