|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com 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.