RE: WebSphere Java Heap Configuration -- MIDRANGE-L

Dean is correct. There never was a 32-bit classic. Good reference material here for supported versions: http://www-01.ibm.com/support/docview.wss?uid=nas8N1011999

The Runtime class gives you access to current memory usage. I've built a little jsp that puts back a webpage I use it to spot-check usage. It would be pretty simple to make it into a daemon thread on a timer that would write to a log with usage info on a regular basis.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<HTML>
<HEAD>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="IBM Software Development Platform">
<TITLE>Status.jsp</TITLE>
</HEAD>
<BODY>
<H1>WorkflowWebService Status</H1>
<pre>
Available Processors = <%= Long.toString(Runtime.getRuntime().availableProcessors()) %>
Free Memory = <%= Long.toString(Runtime.getRuntime().freeMemory()) %>
Total Memory = <%= Long.toString(Runtime.getRuntime().totalMemory()) %>
Max Memory = <%= Long.toString(Runtime.getRuntime().maxMemory()) %>
</pre>
</BODY>
</HTML>

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Dean, Robert
Sent: Thursday, October 03, 2013 5:08 PM
To: Midrange Systems Technical Discussion
Subject: RE: WebSphere Java Heap Configuration

The classic JVM never came in a 32-bit flavor.

You typically want to run with a smaller initial heap size than your maximum.
To do otherwise affects the behavior of the garbage collector in less than
friendly ways. My recommendation would be tracking the memory usage
during peak usage and set the initial heap size in that neighborhood, with the
maximum heap size somewhat greater to handle spikes.

Using a separate memory pool is a good recommendation. It needs to be
bigger than your maximum heap size with some extra thrown in for
native/off-heap memory usage.

If your application can support it, moving it to a more recent WebSphere and
IBM i 7.1 would allow taking advantage of advances in JVM technology since
Java 5 (particularly in the garbage collection/memory management space), as
well as efficiencies in WAS itself. In addition, WAS 6.1 just went out of
support.
________________________________________
From: midrange-l-bounces@xxxxxxxxxxxx [midrange-l-
bounces@xxxxxxxxxxxx] on behalf of Dan Kimmel
[dkimmel@xxxxxxxxxxxxxxx]
Sent: Thursday, October 03, 2013 5:55 PM
To: Midrange Systems Technical Discussion
Subject: RE: WebSphere Java Heap Configuration

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.

--
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.