We have two batch queues for each of our labs: a "short" one that has a 1 week h_rt limit and a "long" one that has no time limit. We guarantee (as best as possible) that short queue jobs complete within the h_rt request by either using calendars (for queue-wide outages) advance reservations (for single-node outages) added at least a week before the maintenance.
For everything besides run-time limits, we use resource requests rather than queues. There's just so many resources available, that queues are overkill and tend to encourage partitioning the cluster excessively. On Fri, Oct 21, 2016 at 11:25:37AM -0400, Michael Stauffer wrote: > > > > Maybe it would be good to tell the user not to submit into a queue at all > > but request resources and SGE will select an appropriate queue for the job. > > > > I have two main queues. all.q, which is a batch queue for newer compute > nodes, and basic.q which is a batch queue for older, slower nodes that are > used much less often. I also have a separate queue for qlogin sessions (if > I remember right, I setup a separate qlogin queue a long time ago when I > first set this system up so I could have a time-limit on sessions). Would > it make sense to have a resource that differentiates between these queues > that user's would request in order for SGE to choose the appropriate queue, > or leave it as I have it currently, in which all.q is the default, and if a > user wants to run on basic.q, they request it manually via qsub -q option. > > I'll probably be adding some queues soon that have different time limits, > to better corral long-running jobs. I know there's a mechanism for doing > this, but haven't looked into it yet. I imagine it' what you're suggesting > here? > > > > > and I hadn't looked carefully enough to notice that. So now I'm not sure > > about the couple other times I've seen this in the past, it might have been > > something like that. > > > > > > Skylar thanks for the qstat -w tip, I'll use that in the future. > > > > > > Reuti, if I were to adjust the setup not to use RQS, how would I limit > > users' resource usage? > > > > It was only suggested as a test. I saw situations where a combinations of > > consumables and limits in RQS blocks the scheduling completely and showing > > something like "... offers only (-l none)." > > > > In case you have to limit the usage per user you have to use them for sure. > > > > OK thanks, I thought you maybe were suggesting there's another way to limit > resources by user. > > -M > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
