Hi,

As an addition to this i'd like to add that if you are not explicitly 
increasing your permanent generation then I'm not surprised that many JSPs 
would fill it up. You will probably find that the default Maximum size of the 
Permanent generation is 64MB and it is that which is filling up and not the 
full 1850MB of your heap.

A tool you should look into is jvmstat which is available from sun and gives 
you a grahical representation of the heap real time so you can see what is 
running out.

As a tip -XX:MaxPermSize=256M might be a good option for your JAVA_OPTS.

Ta
Matt

-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, December 10, 2004 2:00 PM
To: Tomcat Users List
Subject: RE: Tomcat Running out of Memory



Hi,

>-Our consultant-designed website consists of approximately 5000 JSP
>pages.  None of these pages pull from a backend, the java was merely
>used to provide a persistent border.

Are these JSPs precompiled?

>-Max heap size is set to 1850 megs, (which from what I understand is
the
>max on a 32-bit system).

It's not.  The max in JDK 1.4 is 2GB for the vast majority of 32-bit
platforms, including yours.  You'd have to search far and hard to find
any platform that imposes a memory limit that's not a power of 2 ;)

>-The server has 4 gigs of total RAM.

Which doesn't matter because you're only giving the JVM 1850MB.

>I've done some searches on Google and in the archives and I can't seem
>to find any way to turn up the frequency of the garbage collection.

To turn up the frequency of garbage collection, you would use several
JVM options, as documented at
http://java.sun.com/docs/hotspot/VMOptions.html.  In fact, the related
document at http://java.sun.com/docs/hotspot/gc1.4.2/index.html is vital
reading.

>Everything seems to indicate that once a JSP is loaded into memory it
>stays there.

Why wouldn't it?  It's a compiled class that goes into the permanent
generation (not the heap).  Classes themselves (as opposed to their
instances) would be unloaded only if possible and only at time of dire
memory trouble, as judged by the VM.

>Is there some way to increase the max heap size?

Yes, using the -Xmx parameter.

>Or some way to increase the frequency of garbage collection?

Yes, see the VM options above.

>Or any other way to slow down the memory usage?

Yes, to critically inspect the design and implementation of your app
such that less memory is used.  This is typically a performance
tradeoff, as you would cache and retain less in memory, leaving more in
the database or disk as needed.

If you're not precompiling your JSPs, you should: compiling 5000 JSPs is
a significant drain on resources, although those resource should largely
be released.  See the note on javac's memory leak in Tomcat's release
notes.

Yoav Shapira http://www.yoavshapira.com




This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary 
and/or privileged.  This e-mail is intended only for the individual(s) to whom 
it is addressed, and may not be saved, copied, printed, disclosed or used by 
anyone else.  If you are not the(an) intended recipient, please immediately 
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Any opinions expressed in this E-mail may be those of the individual and not 
necessarily the company. This E-mail and any files transmitted with it are 
confidential and solely for the use of the intended recipient. If you are not 
the intended recipient or the person responsible for delivering to the intended 
recipient, be advised that you have received this E-mail in error and that any 
use or copying is strictly prohibited. If you have received this E-mail in 
error please notify the beCogent postmaster at [EMAIL PROTECTED]
Unless expressly stated, opinions in this email are those of the individual 
sender and not beCogent Ltd. You must take full responsibility for virus 
checking this email and any attachments.
Please note that the content of this email or any of its attachments may 
contain data that falls within the scope of the Data Protection Acts and that 
you must ensure that any handling or processing of such data by you is fully 
compliant with the terms and provisions of the Data Protection Act 1984 and 
1998.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to