-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 1/14/2010 11:48 AM, Leo Donahue - PLANDEVX wrote:
> Thank you for the feedback. I followed Chuck's advice and set the
> initial and maximum memory pool using the tomcat6w.exe I have both
> values set to 512MB.
As Chuck suggests, that's a bit small, especially if you are
manipulating large data sets. I suspect that a GIS data set is quite
large, though with an 87MiB heap size after initialization, I would
guess that you don't need it all.
(Chuck: we use a 196MiB heap for our "big" webapp and it's working fine! :)
> Windows Server 2003 Standard SP2 32-bit
> Tomcat 6.0.20
> The Java Virtual Machine: C:\Program
> Files\Java\jdk1.6.0_14\jre\bin\server\jvm.dll
>
> Looking at the log files, the OOME appears in the logs after long
> periods of time. Yesterday the message did not appear in the logs
> until 1:50 AM.
What time did you start it? :)
> When Tomcat starts, it is consuming around 87MB of memory and by
> tomorrow it will grow to around 118MB and somewhere in between there
> will be a OOME message in the logs. The webapp still works though.
Okay, I'll bet I know what's happening. Since your webapp works properly
after the OOME, and the heap is still relatively small (118MiB heap size
while the maximum is 512MiB). I think what's happening is that your
webapp, during one request, is trying to allocate a whole bunch of
memory all at once: it's probably trying to load a ton of GIS data from
a larger database, or maybe trying to do something with an image that
ends up being rather large. The allocation fails, the OOME is thrown,
but neither the application nor the JVM suffers: subsequent requests are
properly handled... it's just that one request that fell on its face.
I'm not sure if you can trigger a thread dump on OOME, but that would be
very interesting: if one thread always says that it's running a method
called allocateHugeArray() or something, that may be your culprit.
Do the ArcIMS folks recommend a particular heap size for use with their
API / database? You might want to consult with them about an
appropriately-sized heap for your needs.
Was ArcIMS designed to be used in a multi-user environment? It's
possible that you can't get decent performance with multiple
simultaneous queries against their database. In that case, all is not
lost: you can write your own wrapper around the ArcIMS API that will
limit the number of simultaneous requests to something more manageable.
> I realize that my issue is now probably not related so much to Tomcat
> but probably the design of the webapp.
This is usually the case, although Tomcat bugs /have/ been found in the
past.
>>> Do you keep a lot of information in users' sessions?
> I don't know, I'm only keeping one string value which is what the
> user enters into the query text field. The session timeout is set to
> 5 minutes.
If you're talking about the search string from below ("211-52-011A"),
then this is what we call "nothing". Don't worry about this. The memory
allocated for management of the session itself (very small) outweighs
this trivial amount of memory to store that string. Unless you don't
limit the length of the string you're willing to accept via the web
interface and/or store in the session. You might want to check that.
>>> How about in the application context?
> I'm not using any init params, if that is what you mean.
No, that's not what I mean. Many applications do some preliminary work
when they start up, maybe by loading static data from a database and
caching it in what's called the "application scope" which is represented
by a ServletContext object.
You can get a lot of information about what is where using a utility I
wrote called the SessionSnooper. You can find it here under "JSP
Utilities": http://christopherschultz.net/projects/java/
You can see what is being stored where in your web application
(application, session, and request scopes). You can also get JVM memory
information, too. This might help you see what is being stored in there,
although it doesn't do anything cool like try to calculate the "size" of
anything. It just tells you the hash keys (which are string values) and
allows you to print the result of toString() called on each item.
>>> Does your webapp do anything that you expect to require very
>>> heavy memory consumption (image manipulation, in-memory
>>> representations of large datasets, etc.)?
>
> For each request, if the value is found in the datasource, up to 40
> other beans are instantiated and compared to the result of the
> request. There is also one image that is returned in the process.
> You can view it here: http://planning.maricopa.gov/plannetquickinfo
Depending on the size of these beans, you might have a situation where a
lot of memory is allocated all at once due to one of these requests. If
it comes down to it, you might have to use a debugger to see what is
happening.
Definitely enable some kind of access logging. You might even want to
add some debugging logging to your webapp that prints information like
what requests are being made to the ArcIMS API, including all the
parameters that are being sent. If you can figure out how to reproduce
your OOME, you can figure out why it's happening and how to prevent it.
Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktQgqkACgkQ9CaO5/Lv0PBR8QCggykevkEhbEWfXxrTWza1EeW7
cvwAoJ1nhRlcfHWNHGggu4n/R+aJbY6Z
=O2AB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
