[gridengine users] RQS and scheduler performance (max-slots-on-all-hosts)

Stuart Barkley stuartb at 4gh.net
Thu Apr 26 19:08:00 UTC 2012

On Thu, 26 Apr 2012 at 13:33 -0000, Joshua Baker-LePain wrote:

> Well, this is disappointing.  I noticed something similar with our rather
> ancient 6.1u3 install -- scheduling runs were taking a long, long time
> whenever anybody submitted jobs to our PEs, and setting "max_reservation 0"
> made them run much more quickly.  We do have 4 RQSs, but I haven't tried
> disabling them as they are rather essential to our setup.  In all cases,
> schedd_job_info was set to false.
> I'm in the midst of installing hardware for a new server on which I'll be
> running a much newer SGE version.  I was rather hoping that this would allow
> me to get reservations, RQSs, and "schedd_job_info true" (since it is rather
> handy) all working together.  Apparently not...

I wouldn't let my issue discourage you.  I think the issue is of
limited scope, not all RQSs have issues.

I brought this up in part because this specific RQS is often mentioned
as being useful.

I do have a couple other RQSs defined.  These other ones don't seem to
cause issues.  I think something in the max-slots one is causing the
main issue (possibly iterating over all hosts for every job

For the record I have the following:

  % qconf -srqs
     name         max-slots-on-all-hosts
     description  "Don't over commit host slots"
     enabled      FALSE
     limit        hosts {*} to slots=$num_proc
     name         maint-nodes
     description  "Nodes requiring to hardware maintenance"
     enabled      TRUE
     limit        hosts {@maint} to slots=0
     name         user-slot-limit
     description  "Limiting slots for specific users."
     enabled      TRUE
     limit        users stuartb to slots=99999
     limit        users user1 to slots=1000
     limit        users user2 to slots=99999

I also find it handy the you can use "qconf -mrqs" to change all of
the RQSs at once (including renaming them).  I don't think any of the
other -m* options work in a similar fashion.

I've never been lost; I was once bewildered for three days, but never lost!
                                        --  Daniel Boone

More information about the users mailing list