[GE users] CLIENT parameter values in JSVs

macona ashley.macon at colorado.edu
Mon Nov 1 21:21:36 GMT 2010

Sorry, my last post may have been unclear. Please allow me to try and elaborate...

We are trying to control job memory usage in an environment where most users will not know how much memory their programs require.  Thus far, we have not constrained nor controlled memory usage. However, we now have jobs which are long running and must run on nodes that are protected from memory overconsumption by other jobs assigned to the same node(s).

We are now running/trying 6.2u6 (for fixed maxvmem reporting, so that users can now know how much memory their jobs consumed).

I have these queues: strict.q (spans 5 nodes), free.q (spans 20 nodes) and all.q (spans aforementioned 25 nodes), interactive.q (spans 1 node)

/*****---------------------/ strict.q
/-----********************-/ free.q
/*************************-/ all.q
/-------------------------*/ interactive.q

The idea is to give new users a place to run their jobs free from constraints (free.q) so that they can learn how much memory their jobs require.

But we also need a safe place to run sensitive long-running jobs (strict.q), as well as the ability for some jobs to use the entire cluster (all.q) (while not compromising jobs in strict.q).

I am using a JSV to set the q_hard parameter to 'free.q' for all jobs that do not explicitly request h_vmem. There is an exception, however, which is that I need to allow interactive jobs to be assigned to 'interactive.q' though they will not explicitly request h_vmem. 

I am able to do this as a client-side JSV by evaluating the CLIENT parameter, and when it is set to 'qrsh' setting q_hard to 'interactive.q' and returning from the JSV. For non-qrsh jobs, the script examines whether h_vmem is set and if not assigns q_hard to 'free.q'.

This JSV works fine as a client-side JSV. It does not work as a server-side JSV, as the CLIENT parameter is set to 'qmaster' and thus I have no way (yet) to distinguish interactive job from any other job not requesting h_vmem.

Any advice or alternative setup suggestions is very much appreciated!

> removing the "INTERACTIVE" from "qtype" list in the queue's definition is not an option, or do you want it just for `qrsh` but not `qlogin`?
I'm sorry, I don't understand. I assumed the queue type needs to be set to INTERACTIVE for qrsh/qlogin jobs...only one of our queues 'intactive.q' has this queue type set, the others are simply BATCH.


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list