Yeah - that's why I went with a server side JSV. My users cannot override it, and if they forget to request, the job will at least run (until they exceed the 4GB default - which they do regularly).
On Wed, Feb 25, 2015 at 6:47 AM, Reuti <re...@staff.uni-marburg.de> wrote: > Am 25.02.2015 um 15:26 schrieb Feng Zhang <prod.f...@gmail.com>: >> >> On Wed, Feb 25, 2015 at 6:44 AM, Simon Andrews >> <simon.andr...@babraham.ac.uk> wrote: >>> >>> >>>> From: Mishkin Derakhshan <mishkin...@gmail.com> >>>> Date: Tuesday, 24 February 2015 00:07 >>>> To: "users@gridengine.org" <users@gridengine.org> >>>> Subject: [gridengine users] How to set up h_vmem as a consumable >>>> resource >>>> >>>> We _think_ this has to do with setting a default h_vmem (on a queue >>>> basis? host basis?) so jobs that >>>> don't explicitly request the resource will use something by default, but >>>> we've been unable to figure >>>> out how to set this up. >>> >>> I don't think that not adding h_vmem should result in a zero allocation - >>> quite the opposite, if you don't add a default allocation then you can use >>> infinite memory. >>> >>> We tried a couple of ways to enforce this. We started putting the -l >>> h_vmem=1G (or whatever) in the $SGE_ROOT/default/common/sge_request file >>> so it gets added to all jobs by default, however the users can remove this >>> by putting -clear on their submissions. We've now moved to using a server >>> side job submission verifier (JSV). I'd be happy to send you the script >> >> Just came into my mind, that use JSV to disable "-clear" option, and >> use "sge_request" to set defaults? > > According to `man jsv_script_interface` "-clear" is not available in JSV as > it's not a real parameter. > > -- Reuti > > >>> we use, but its a little more complex than you might need in that we only >>> add the h_vmem to batch jobs and we leave interactive jobs unrestricted. >>> >>> That seems to be working really well for us. >>> >>> Simon. >>> >>> The Babraham Institute, Babraham Research Campus, Cambridge CB22 3AT >>> Registered Charity No. 1053902. >>> The information transmitted in this email is directed only to the >>> addressee. If you received this in error, please contact the sender and >>> delete this email from your system. The contents of this e-mail are the >>> views of the sender and do not necessarily represent the views of the >>> Babraham Institute. Full conditions at: >>> www.babraham.ac.uk<http://www.babraham.ac.uk/terms> >>> >>> _______________________________________________ >>> users mailing list >>> users@gridengine.org >>> https://gridengine.org/mailman/listinfo/users >> >> >> >> -- >> Best, >> >> Feng >> >> _______________________________________________ >> users mailing list >> users@gridengine.org >> https://gridengine.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
