[7920] 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 (Jonathon Weiss)
Mon Jun 3 18:22:17 2013

Message-Id: <201306032222.r53MM6nE002441@outgoing.mit.edu>
To: Alex T Prengel <alexp@MIT.EDU>
cc: Jonathon Weiss <jweiss@MIT.EDU>, linerva-root@MIT.EDU,
        release-team@MIT.EDU
In-reply-to: <1367524643.7051.9.camel@dit>
Date: Mon, 03 Jun 2013 18:22:06 -0400
From: Jonathon Weiss <jweiss@MIT.EDU>


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