On 14/01/2010 16:48, Leo Donahue - PLANDEVX wrote:
Chris,
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.
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.
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.
I hope I can answer the following but I'll admit to you now, I'm not 100% sure
I know what I'm doing. Hopefully you will keep the laughter to a minimum as a
courtesy?
I realize that my issue is now probably not related so much to Tomcat but
probably the design of the webapp.
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 the string value is short, probably not then.
How about in the application context?
I'm not using any init params, if that is what you mean.
Sort of.
Does your webapp cache a lot of information?
I don't know.
OK.
Do you use a database connection pool? If so, which one? What is the
configuration?
No. I am using a vendor API that makes a connection to their datasource. The
user enters a value in the JSF page, the action event is tied to a method that
looks up the value in the datasource, if the value was found then page
navigation ocurrs and displays results, if the value was not found a message is
displayed on the JSF page indicating the value was not found, using the
messages tag.
A resource leak is when, for example, a database connection is opened
but not properly closed. Each time it's opened it's using a bit of
memory that isn't returned, because the connection is not closed.
It can be hard, but not impossible, to track down the source of this
type of problem.
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
You can use parcel: 211-52-011A as an example search.
Where does the image come from and how is it handled? Sometimes image
generation can be a problem.
Have you had to write any code to make the app work?
p
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, January 13, 2010 2:03 PM
To: Tomcat Users List
Subject: Re: Tomcat memory settings
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 1/11/2010 2:29 PM, Leo Donahue - PLANDEVX wrote:
org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet "servlet name" threw exception
java.lang.OutOfMemoryError: Java heap space
To add to what others have said, getting an OOME can mean one of two things:
1. Your webapp simply needs more memory than you are allocating 2. You have a
resource leak
Most often, #2 is the culprit.
Under what conditions are you getting the OOME? Lots of users after a short
period of uptime, or all by yourself on your development environment after a
long period of time?
Do you keep a lot of information in users' sessions? How about in the
application context? Does your webapp cache a lot of information? Do you use a
database connection pool? If so, which one? What is the configuration?
Does your webapp do anything that you expect to require very heavy memory
consumption (image manipulation, in-memory representations of large datasets,
etc.)? If so, you may simply need more memory to properly run your webapp.
Finally, with a 32-bit JVM (you didn't say which you were using), you'll
top-out around 2GiB for your heap no matter how much physical RAM you have. If
you need more than 2GiB of heap, you'll need to go with a 64-bit environment.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktONOkACgkQ9CaO5/Lv0PAEMACfaS7G/FPgvCkEG1j4tS7mQkrC
PkgAn3CYEh4D8eEa4FJdlLAIp7VmOIWZ
=/cyT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
