[GE users] Dynamic queue -- sge schedule policy
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
You can adjust the scheduler load_formula to take this sequence number into account
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.
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