[GE users] CLIENT parameter values in JSVs

reuti reuti at staff.uni-marburg.de
Mon Nov 1 21:57:43 GMT 2010


Am 01.11.2010 um 22:21 schrieb macona <ashley.macon at colorado.edu>:

> 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).

For the paid version there is a dedicated forum set up:

http://forums.oracle.com/forums/forum.jspa?forumID=859

Also note, that there is a fork Open Grid Scheduler which should also  
fix this problem.


> 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.

Sorry for the confusion, I meant to remove INTERACTIVE from the other  
queues, except the interactive.q, as you already did.

The solution might then be to assign interactive.q and free.q (yes,  
both) for jobs not requesting h_vmem. SGE can only schedule it to one  
in the end, depending on its type.

-- Reuti  


> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291879
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=291889

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



More information about the gridengine-users mailing list