Re: WebSphere Java Heap Configuration

It's using JDK 1.5.0 (so many names, so many different JVM's...)

We do have a dedicated pool assigned to a specific subsystem for the JVM
and it is larger than than maximum heap size.


My understanding is that the JVM will not grow beyond that maximum heap
size plus some additional memory overhead - maybe I have that wrong. What
I'd like to get to is a situation where the JMV has access to as much
memory as it needs or can use.

If I manage to achieve that I may need to scale it back to what is
practically available to the system, but finding out what the maximum it
could use if all resources were available to it seems a reasonable starting
point.

Maybe I;m just going about it wrong, in which case feel free to educate me
:)




On Fri, Oct 4, 2013 at 10:55 AM, Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx> wrote:

Which JVM are you using? You say 32 bit, but you don't say which version
of java or whether you're running the classic JVM or J9 JVM. It makes a
difference.

I don't run WAS, but I do run Tomcat on a lot of customer machines. I've
found in these volatile memory environments where objects are created and
abandoned very frequently, that the Java garbage collector really doesn't
play well with IBMi memory management, so I try very hard to allocate
enough memory so the heap doesn't have to be paged. I've had the best
success running the web container in its own subsystem with a dedicated
memory pool. The memory pool should be big enough to hold the code and the
heap. Contrary to recommendations, I make the initial and maximum heap size
the same. The recommendation not to do so comes because the jvm can run
itself out of heap space in this configuration and it will stop. It will do
the same when it hits the maximum, so I don't see the difference. What I
find is that the garbage collector will run more frequently as the maximum
heap size is approached.

The garbage collector wants to touch all the objects that have become
unreachable. Usually, when the memory pool size has been exceeded, those
objects have been paged out to disk as they haven't been referenced
recently. To page them back into memory, the system must page some other
objects out. Memory management starts to thrash; that is, it spends more
time copying stuff back and forth to disk than it does doing actual work.
If you can avoid filling the memory pool, everything run much, much more
quickly.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Thursday, October 03, 2013 2:52 PM
To: Midrange Systems Technical Discussion; Web Enabling the AS400 /

iSeries

Subject: WebSphere Java Heap Configuration

Cross-Posted on Web400; Midrange-l

I have a customer running WebSphere 6.1 on an IBM i hosts V6R1. Currently
this implementation is being tested as part of a performance evaluation
process as the application back end database is run on the same IBM i. We
are running WAS with its own dedicated pool of memory.

One of the things we have looked at is how to increase the memory size

(if

possible) for the WebSphere Server instance. We currently have this
configured with an initial heap size of 0 and a maximum heap size of 1380
and it runs quite OK. We are running a 32 bit JVM at this point in time

but

may move to the 64 bit JVM to see what results that provides

According to the documentation I have read, setting the Initial Heap size
to 96 and Maximum Heap Size to 0 should cause the maximum heap size to
be
effectively "nomax". (setting the hap sizes to the same value is not
recommended). However setting the heap sizes this was basically causes

the

server to start doing heap dumps and fail.

What do others do to maximise the amount of memory available to the
.application being run by WebSphere ? Has anyone got the recommended
settings to work or some other variation ?

Any advice appreciated.

--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.