Hi, Am 19.12.2012 um 18:13 schrieb Ian Kaufman:
> Well, that is what you asked for - setting it to YES means applying it per > slot per the man pages. > > What kind of behavior are you really looking for? If set to JOB, then the > resource is debited from the queue resource, which in your case, has no limit > (h_vmem is set to INFINITY). So, since there is no queue limit set, SGE > ignores the host limits when set to JOB, and you can oversubscribe. I disagree here. The tighther limit should be take. Sometimes negative values show up for unknown reason. If it should be consumed from a queue instance, it would be necessary to attach the it to complex_values also to the queue (this is per queue instance), but the limit further down in the queue definition is per job. -- Reuti > Ian > > > On Wed, Dec 19, 2012 at 8:57 AM, Brett Taylor <[email protected]> wrote: > Ok, that seems to be working, but it changes the submission time `-l h_vmem=` > to be per thread instead of per job. Not a big deal, just a little annoying > to have to calculate each time. > > > > Thanks > > > > Brett Taylor > > Systems Administrator > > Center for Systems and Computational Biology > > > The Wistar Institute > > 3601 Spruce St. > > Room 214 > > Philadelphia PA 19104 > > Tel: 215-495-6914 > > Sending me a large file? Use my secure dropbox: > > https://cscb-filetransfer.wistar.upenn.edu/dropbox/[email protected] > > > > From: Ian Kaufman [mailto:[email protected]] > Sent: Wednesday, December 19, 2012 11:37 AM > To: Brett Taylor > Cc: [email protected] > Subject: Re: [gridengine users] vmem allocation > > > > Hi Brett, > > Try setting consumable to YES instead of JOB. > > Ian > > > > On Wed, Dec 19, 2012 at 8:05 AM, Brett Taylor <[email protected]> wrote: > > Hello, > > > > I seem to be having some issues with the h_vmem setting and proper > allocation. I was under the impression that this would function much like > the CPU slots, and once all of the h_vmem had been allocated, that host would > not accept more jobs. This however does not seem to be the case. I have two > queues running on the same nodes. > > > > My hosts are defined: > > > > complex_values slots=48,h_vmem=95G > > > > complex config: > > > > #name shortcut type relop requestable consumable > default urgency > > #---------------------------------------------------------------------------------------- > > h_vmem h_vmem MEMORY <= YES JOB 4G > 0 > > > > queue config, in both queues: > > > > slots 24 > > h_vmem INFINITY > > > > So if I submit one job to A.q, using –l h_vmem=95G, then `qstat -f -u "*" -F > h_vmem` shows: > > > > --------------------------------------------------------------------------------- > > [email protected] BIP 0/24/24 1.02 lx26-amd64 > > hc:h_vmem=0.000 > > 3970 0.60500 bt_script. btaylor r 12/17/2012 11:26:45 24 > > --------------------------------------------------------------------------------- > > [email protected] BP 0/0/24 1.02 lx26-amd64 > > hc:h_vmem=0.000 > > > > but if I then submit to the 2nd queue, the h_vmem will go negative and allow > both jobs to run at the same time: > > > > --------------------------------------------------------------------------------- > > [email protected] BIP 0/24/24 1.01 lx26-amd64 > > hc:h_vmem=-95.000G > > 3970 0.60500 bt_script. btaylor r 12/17/2012 11:26:45 24 > > --------------------------------------------------------------------------------- > > [email protected] BP 0/24/24 1.01 lx26-amd64 > > hc:h_vmem=-95.000G > > 4012 0.60500 bt_script. btaylor r 12/19/2012 11:03:04 24 > > > > > > Is this not supposed to act like the cpu slots? Any ideas on how I might be > able to treat available vmem the same as the cpu slots? > > > > Thanks, > > Brett > > > > > > > > Brett Taylor > > Systems Administrator > > Center for Systems and Computational Biology > > > The Wistar Institute > > 3601 Spruce St. > > Room 214 > > Philadelphia PA 19104 > > Tel: 215-495-6914 > > Sending me a large file? Use my secure dropbox: > > https://cscb-filetransfer.wistar.upenn.edu/dropbox/[email protected] > > > > > _______________________________________________ > 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 > > > -- > This email was Anti Virus checked by Astaro Security Gateway. > http://www.astaro.com > > > > -- > 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 _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
