You can also set the "sge_request" file with the -l h_vmem to provide all jobs with a default value. The input value of -l h_vmem by user can override the default one.
On Tue, Feb 24, 2015 at 2:45 PM, Mishkin Derakhshan <[email protected]> wrote: > Thanks to everyone for the responses. > > Ed, we tried increasing h_vmem and regardless of the number, if we submit > a job without the -l h_vmem=x parameter then the job fails. > > The easiest way to deal with the issue is to purchase machines with a > lot of memory... :) > ^- The Truth! haha. > > Bill, thanks for the link and nifty line of code. > > qhost | awk 'NR>3 { print "qconf -mattr exechost complex_values > mem_free=" $8,$1 }' | sh > Unfortunately your link for the discussion is now 404. In your example, > what does $8 refer to, because on mine the 8th column from qhost is SWAPUS > > Arne, unfortunately we are stuck using 6.1u3 for a while as our sysadmin > refuses to change things on our older system. I will look into cgroups once > we get a new system in place, thanks. > > Ian, it sounds like a JSV might be what we need. We are already using a > wrapper to qsub so it shouldn't be too hard to just have all jobs submit > with a default -l h_vmem if none is provided. Seems odd though that there > is no way to set a default value so that jobs without an explicit request > to the resource don't die. > > On Tue, Feb 24, 2015 at 6:58 AM, Ian Kaufman <[email protected]> > wrote: > >> I wound up using a JSV that checked to see if h_vmem was supplied by >> the user, and if not, I supplied a default 4G request in the JSV >> rewrite. >> >> Not sure if JSVs existed in 6.1u3 though. >> >> Ian >> >> On Mon, Feb 23, 2015 at 4:07 PM, Mishkin Derakhshan >> <[email protected]> wrote: >> > Hi, >> > We have some jobs that require significant amounts of memory so we want >> to >> > try and setup h_vmem as a consumable resource to manage this. >> > >> > This is what we have setup: >> > $ qconf -sq dev.q | grep h_vmem >> > h_vmem 3.7G >> > >> > $ qconf -sc | grep h_vmem >> > h_vmem h_vmem MEMORY <= YES YES >> 0 >> > 0 >> > >> > And if we submit jobs like this then we don't have any problems, >> > $ qsub -b y -j y -l h_vmem=1G -q dev.q sleep 100 >> > >> > But if we submit jobs without explicitly requesting h_vmem (i.e., we >> don't >> > use -l h_vmem=X) then the jobs die on startup saying it can't allocate >> > memory: >> > error reason 1: 02/19/2015 14:13:39 [0:14840]: can't set >> > additional group id (uid=0, euid=0): Cannot allocate memory >> > >> > 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. >> > >> > We are using 6.1u3. >> > >> > thanks >> > >> > _______________________________________________ >> > users mailing list >> > [email protected] >> > 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 > [email protected] > https://gridengine.org/mailman/listinfo/users > > -- Best, Feng
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
