[7921] in Release_7.7_team
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
> >
> >
