I tried the using that, but I get the following message: "use parallel environment instead of requesting slots explicity"
any other idea? -rs On Wed, Jun 5, 2013 at 3:05 PM, Ed Lauzier <[email protected]> wrote: > Easiest way was posted awhile back...don't have the link, but I use it all > the time. > > Resource quota setting.... > > { > > name slot_limit_per_host > > description limit number of slots available to nslots > > enabled TRUE > > limit hosts {*} to slots=$num_proc > > } > > > This allows for multiple queues to share the same hosts.... > and not overcommit. > > Hope this helps... > > -Ed > > -----Original Message----- > *From:* William Hay [mailto:[email protected]] > *Sent:* Wednesday, June 5, 2013 04:03 AM > *To:* 'S. Sanchez' > *Cc:* [email protected] > *Subject:* Re: [gridengine users] limiting the number of cores per node > > > > > On 5 June 2013 08:32, S. Sanchez <[email protected]> wrote: > >> Dear William, >> >> Thanks for your response. Yes, I know that the admin can do this for me >> and save me time, but the an 8-core parallel environment may not solve my >> problem in terms >> > > My point wasn't that the admin could do it for you but that they were a > better source for information on how to do it than the list. The problem > is that grid engine is sufficiently flexible that there is no general > solution. > > of flexibility. That is, there could be instances in which, I want a job >> running 6 cores in node#1 and 6 cores in node#2. That is why, I am asking >> for a non-admin solution. >> >> For example, is there a way to restrict the number of cores per node on a >> memory basis? >> > > It depends if the admin set the memory complex as a per slot consumable. > If so your memory request will be per slot and grid engine won't pack > slots more tightly than dictated by that. > > >> Or more simply, is there a way (at all) at the user-level to restrict >> the number of cores per node? >> >> > In the out of the box config I don't think there is. But IIRC the out of > the box config doesn't have any configured PEs(except I think the Univa > version) either so you almost certainly aren't running an out of the box > config and only your local admin knows how it is configured. > > >> >> >* hi, >> *>* >> *>* i am trying the number of cores per node and i checked google and i >> found >> *>* the following link: >> *>* >> *>* >> http://comments.gmane.org/gmane.comp.clustering.gridengine.users/18883 >> *>* >> *>* but, i can't access all the links provided in this website. >> *>* >> *>* so, my question is: how can i limit the number of cores per node? I >> want >> *>* to use say 8 cores of node # 1 and 8 cores of node # 2 in a cluster >> that >> *>* contains only 16-core nodes. >> *>* >> *>* any ideas? i don't have admin rights to create a new queue or >> something >> *>* like that. i am trying to find a solution that a non-admin user can >> *>* implement. >> *>* >> *>* >> *Ask whoever does have admin rights. Grid Engine is a very flexible >> scheduler that can be set up in a number of ways. If the admin has set >> one up you could use a PE with an allocation_rule of 8. Otherwise you >> could look for a per slot consumable resource that you don't care about >> and >> request 1/8th of the amount available per host. This would only work if >> the scheduler is set up so that you get or can request exclusive access to >> the hosts. >> >> >> >* best, >> *>* -rs >> *>* >> * >> >> On Wed, Jun 5, 2013 at 8:12 AM, S. Sanchez <[email protected]> wrote: >> >>> hi, >>> >>> i am trying the number of cores per node and i checked google and i >>> found the following link: >>> >>> http://comments.gmane.org/gmane.comp.clustering.gridengine.users/18883 >>> >>> but, i can't access all the links provided in this website. >>> >>> so, my question is: how can i limit the number of cores per node? I want >>> to use say 8 cores of node # 1 and 8 cores of node # 2 in a cluster that >>> contains only 16-core nodes. >>> >>> any ideas? i don't have admin rights to create a new queue or something >>> like that. i am trying to find a solution that a non-admin user can >>> implement. >>> >>> best, >>> -rs >>> >> >> > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users > >
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
