Thanks for your suggestions. We have over a hundred applications and
that is why it is difficult to focus in one area. We will consider your
ideas and add them to our list of things to investigate.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Sam Shirah
Sent: Friday, April 11, 2008 2:06 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Websphere Heap Analysis tools

Hi Connie,

One of my clients had a similar problem last year. Typically there
two potential causes. However, if you're set up as standard, it really
to one.

The first (that usually is not relevant) is that there's not enough
memory allocated, disk swapping starts and the gc can't keep up,
running into an Out of Memory exception. The reason this is usually not
issue (except as a by product) is that standard setup grabs more memory
needed without a max limit, unlike Sun JVM's. Assuming an AS/400 with
adequate memory, this case won't happen in a well behaved system.

Usually the cause is a runaway query of some description.

In the case I saw, the app pulled sales appointments. However, the
table was also used by employees for vacation days, time off, sick days,

etc. Because they insisted on using stored procedures, I had no
into what was going on, until I stepped in myself to analyze things.
out the stored procedure was picking up *all* the other junk for each
tons and tons of data, and eventual OOM.

Another case is an unanticipated cartesian join. At another shop
when I was an employee, someone managed to create one of those using
and actually filled up the hard drives!

Some combination of those are the most likely causes. Others are
closing ResultSets and associated objects, having sessions that don't
out, and so on.

One tool that is helpful and free, although not necessarily the
best, is
the Heap Analyzer that comes with iDoctor:

I hadn't heard of Heapana, but after a quick look, it appears that
may be the base for the one in iDoctor, although those tools are newer.

Even with tools, it's likely that you're in for some detective work.

Dynamic queries are the place to start, although even static ones can
grief if unexpected data is being included.

Joe Sam

Joe Sam Shirah -
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum:
Just the JDBC FAQs:
Going International?
Que Java400?

----- Original Message -----
From: "Goins, Connie" <cgoins@xxxxxxxxx>
To: <java400-l@xxxxxxxxxxxx>
Sent: Friday, April 11, 2008 10:29 AM
Subject: Websphere Heap Analysis tools

Recently, we have been experiencing heap spikes in Websphere,
forcing us to bounce our WAS server. We were on WAS 5.1 when this
began, but have recently upgraded to WAS 6.1. We are still
the heap spikes a few times a week. We have some 3rd party software
running on our system, but we primarily develop our own web
using Java. What are some good heap analysis tools to help us focus
research? Heapana data shows us that the system is creating millions
objects, but some are commonly-used objects. How do we determine the
application most responsible? We did some research last year on the
and it appears the settings are acceptable. We believe this is an
application problem, but need help to narrow our search. We cannot
reproduce the situation in test.

System config: WAS 6.1, i5 570, V5R4.

Any ideas would be appreciated. What tools have helped people the
whether WAS 6.1 tools, open source tools, or 3rd party tools?



This is the Java Programming on and around the iSeries / AS400
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.