[GE users] Dynamic queue -- sge schedule policy

John Tseng jtseng at montalvosystems.com
Mon Aug 28 16:58:10 BST 2006

    [ The following text is in the "utf-8" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some characters may be displayed incorrectly. ]

On Monday 28 August 2006 00:35, Juha Jäykkä wrote:

> > In this context, a qsub would like this.
> > qsub -q mem4G.q -soft -l mem4g=1 -hard  myscript
> This seems rather complicated - especially for the end user who never
> remembers the proper qsub parameters anyway. =)

We have a wrapper around qsub which 'remembers' all the relevant qsub options.
This gives you a layer of abstraction to play with various sge options.

my_qsub -jobtype mem4G myscript
==> qsub -q mem4G.q -soft -l mem4g=1 -hard  myscript

The 'jobtype' gets expanded to the qsub options which can change from day-to-day.

> Is there not an easier way? Reuti suggested a simpler solution, but I'm
> afraid of what happens if we go from sorting by load to sorting by
> seq_no.

You can adjust the scheduler load_formula to take this sequence number into account

qconf -ssconf:
load_formula                      np_load_avg

load_formula                      np_load_avg+seq_no

The higher the sequence number, the less likely it will be choosen.
(the sequence number needs to be an integer)

So your 4G machines might have seq_no 10
and your 16G machines might have seq_no 20
The Seq Number can be set per hostgroup per queue

Personally, I would go for the qsub wrapper.  If you have other jobs that have nothing to do with 4G or 16G memory footprints, this will break down quickly.


> This sounds good as well, except that we're not (currently?) interested
> in accounting, we just want to make sure three things happen
> 1) no job takes more memory from a node than is appropriate (that is, 1 G
> per CPU core on most machines and 4 G per core on 16G nodes)
> 2) 16G machines stay free of small jobs as long as there are free cpus in
> small mem nodes
> 3) The machines are filled first according to 2) and then according to
> lowest load.
> Point 1) above is enforced by h_vmem or such - the only problem being
> that some programs put their data in stack and thus effectively
> circumvent vmem limit. =( It is not a big problem, though. Numbers 2) and
> 3) are what I'm trying to configure at the moment.
> -Juha

To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list