[7921] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: linerva / athena.dialup transition

daemon@ATHENA.MIT.EDU (Alex T Prengel)
Mon Jun 3 19:23:33 2013

From: Alex T Prengel <alexp@MIT.EDU>
To: Jonathon Weiss <jweiss@MIT.EDU>
Cc: linerva-root@MIT.EDU, release-team@MIT.EDU, alexp@MIT.EDU
In-Reply-To: <201306032222.r53MM6nE002441@outgoing.mit.edu>
Content-Type: text/plain; charset="ISO8859-1"
Date: Mon, 03 Jun 2013 19:23:23 -0400
Message-ID: <1370301803.23440.14.camel@dit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Thanks a lot for the detailed info; It's probably overkill since no one
complained further after I told them to either use a cluster Athena
machine or Linerva (though I don't know how happy Linerva folks are with
running it there). 

I'll implement one of your suggestions if this comes up again.

                                                     A.

On Mon, 2013-06-03 at 18:22 -0400, Jonathon Weiss wrote:
> The problem here is that chemkinpro by default sets the maximum java
> heap size (-Xmx) to 3072M (on the dialups, based on the architecture and
> amount of memory there).  The dialups have a virtual memory limit of 4G
> per process, and java apparently has at least another 1G of memory it
> wants to allocate, hits the 4G* limit and fails.  You have two options at
> this point.  Which ever one you take, I recommend that you only
> implement it on the dialups (check for the existance of
> /etc/athena/dialuptype to determine if you're on a dialup).
> 
> Option one: Reduce the amount of memory CHEMKIN-PRO is requesting for
> the java heap.  You can do this by setting the CKJAVAMEMORY environment
> variable to "-Xmx2048M" to request a 2G heap rather than 3G.  This is my
> preferred solution of the two.
> 
> Option two: You can raise the virtual memory limit.  As I mentioned it's
> 4G, but that's the soft limit, and the hard limit is 8G.  In this case
> you could use "ulimit -S -v 6291456" (bash) or "limit vmemoryuse
> 6291456" (csh/tcsh) to raise the soft limit to 6G.  However, since the
> dialups are not intended for computationally intensive work, this is a
> less favored option.
> 
> I've tested both solutions, and find that they both work, in that I get
> a GUI control panel.  It's possible that the first solution will run out
> of memory trying to handle larger tasks.  That would be a reason to
> consider the second option.
> 
> * It fails immendiately even if it doesn't try to actually write
>   anything to this memory, even though linux only pretends to allocate
>   the memory until it is used.
> 
> Let me know if you need any additional assistance with this.
> 
> 	Jonathon
> 
> 
> Alex T Prengel <alexp@MIT.EDU> wrote:
> 
> > I ran into a situation last week where a Third Party application
> > (CHEMKIN-PRO) wouldn't run on the dialups but did run on linerva, due to
> > not enough memory being available to the application (it's a Java app).
> > To reproduce:
> > 
> > add chemkinpro; chemkinpro
> > 
> > I told a student she could try running it on linerva (which I presume
> > she did as I didn't hear back). This is in current course use so
> > shutting linerva off before the semester ends could be problematic. It
> > would help if this could run on the dialups.
> > 
> >                                     Alex
> > 
> > On Thu, 2013-05-02 at 11:58 -0400, Jonathon Weiss wrote:
> > > Hello,
> > > 
> > > It's been a little while since we've talked about transitioning linerva
> > > users to athena.dialup.mit.edu.  As you know the athena dialups were
> > > upgraded to Precise in February.  In the process, I believe we added
> > > most of the features that had previously made linerva preferable to the
> > > dialups for some users.
> > > 
> > > While we're unlikely to make changes to athena.dialup.mit.edu between now
> > > and the end of finals, I wanted to get an updated list of what things
> > > are currently blocking or interfering with the transition, so that we
> > > can work on eliminating them.
> > > 
> > > 	Thanks
> > > 	Jonathon
> > > 
> > > 	Jonathon Weiss <jweiss@mit.edu>
> > > 	MIT/IS&T/OIS  Server Operations
> > 
> > 



home help back first fref pref prev next nref lref last post