[7922] in Release_7.7_team
Re: linerva / athena.dialup transition
daemon@ATHENA.MIT.EDU (Alex Chernyakhovsky)
Mon Jun 3 20:08:22 2013
MIME-Version: 1.0
In-Reply-To: <1370301803.23440.14.camel@dit>
Date: Mon, 3 Jun 2013 20:08:11 -0400
Message-ID: <CAB18ysr88_3=4_w7bB5MdFJh=+5hfN829Sz56M0+-kvLrNYvSw@mail.gmail.com>
From: Alex Chernyakhovsky <achernya@MIT.EDU>
To: Alex T Prengel <alexp@MIT.EDU>
Cc: Jonathon Weiss <jweiss@MIT.EDU>, linerva-root@MIT.EDU,
release-team@MIT.EDU
Content-Type: text/plain; charset=ISO-8859-1
Hi Alex,
Linerva is in the process of transitioning the name to athena.dialup,
you should not rely on Linerva continuing to exist.
Sincerely,
-Alex
SIPB Linerva Team
On Mon, Jun 3, 2013 at 7:23 PM, Alex T Prengel <alexp@mit.edu> wrote:
> 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
>> >
>> >
>
>
