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
are
two potential causes. However, if you're set up as standard, it really
gets
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,
eventually
running into an Out of Memory exception. The reason this is usually not
the
issue (except as a by product) is that standard setup grabs more memory
as
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
visibility
into what was going on, until I stepped in myself to analyze things.
Turned
out the stored procedure was picking up *all* the other junk for each
query,
tons and tons of data, and eventual OOM.
Another case is an unanticipated cartesian join. At another shop
back
when I was an employee, someone managed to create one of those using
Query
and actually filled up the hard drives!
Some combination of those are the most likely causes. Others are
not
closing ResultSets and associated objects, having sessions that don't
time
out, and so on.
One tool that is helpful and free, although not necessarily the
best, is
the Heap Analyzer that comes with iDoctor:
https://www-912.ibm.com/i_dir/iDoctor.nsf
I hadn't heard of Heapana, but after a quick look, it appears that
it
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
cause
grief if unexpected data is being included.
Joe Sam
Joe Sam Shirah -
http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum:
http://www.ibm.com/developerworks/java/
Just the JDBC FAQs:
http://www.jguru.com/faq/JDBC
Going International?
http://www.jguru.com/faq/I18N
Que Java400?
http://www.jguru.com/faq/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,
sometimes
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
experiencing
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
applications
using Java. What are some good heap analysis tools to help us focus
our
research? Heapana data shows us that the system is creating millions
of
objects, but some are commonly-used objects. How do we determine the
application most responsible? We did some research last year on the
gc
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
most,
whether WAS 6.1 tools, open source tools, or 3rd party tools?
Thanks.
Connie
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
midrange.com
