Yep, keep monitoring them. Watch the size of PermGen over time. It will
grow as new methods and classes are called.
I was kinda specifically referring to my own situation ("too may
classes"), where I had the same app loaded into multiple instances each
with their own copies of the dependant 3rd-party libraries. It appeared
each app loaded its own version of the library into PermGen, and at some
point (about 6-8 instances) I started seeing the PermGen errors.
Increasing the size only delayed the issue. I ended up moving most of
the libs to the shared directory. That worked for me, mostly, because
it's the same app, just different instances. I have the ability to
upgrade all the instances in lock-step, so it works. It is not a
solution for everybody. (only had a problem with Log4j, and I'm
guessing that was a config issue in the profiles.)
I stated before, I don't think the MaxNewSize option is available
anymore. You should be using NewRatio instead.
Charles, please correct me if my assumption in paragraph 2, sentence 2
was incorrect.
Jeff
-----Original Message-----
From: Bruce Wayne [mailto:chur...@gmail.com]
Sent: Wednesday, September 16, 2009 9:58 AM
To: Tomcat Users List
Subject: Re: java.lang.OutOfMemoryError: PermGen space
What's "too many classes" ? I have JConsole running, and I see that
across
my 8 apps on one server, 14,000 classes are loaded. Heap usage is around
1GB.With the settings below, I am not seeing PermGen errors as of yet,
although it's too early to tell, I will have to let the app run for 24
hours.
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Dfile.encoding=UTF-8
-server
-Xms1024m -Xmx3012m -XX:NewSize=512m -XX:MaxNewSize=1024m
-XX:PermSize=512m
-XX:MaxPermSize=1024m"
On Wed, Sep 16, 2009 at 10:44 AM, Jeffrey Janner <
jeffrey.jan...@polydyne.com> wrote:
> Charles -
> My other post didn't make it back yet.
> Now I'm getting confused, because the same doc I referenced below,
which
> treats Heap and PermGen separately in Appendix B, says this in Chapter
> 3:
> "The detail message PermGen space indicates that the permanent
> generation is full. The permanent generation is the area of the heap
> where class and method objects are stored. If an application loads a
> very large number of classes, then the size of the permanent
generation
> might need to be increased using the -XX:MaxPermSize option."
>
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/memleaks.html
> That is specifically about the error Bruce is seeing.
> But, yes, it appears he's loading too many classes, or reloading them,
> or something.
> Something else Bruce can look into is if his apps are using common jar
> files that can be loaded into Shared space.
> Jeff
>
> -----Original Message-----
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> Sent: Wednesday, September 16, 2009 9:31 AM
> To: Tomcat Users List
> Subject: RE: java.lang.OutOfMemoryError: PermGen space
>
> Chuck -
> I couldn't tell from the post if the Architecture line meant hardware,
> OS, or JVM. And I'm under the impression from multiple re-reads of
the
> Java tuning docs that ALL generations are drawn from the heap,
including
> PermGen.
> Yes, using Jconsole or better is what he needs to do.
>
> Bruce-
> Here is another good read. Direct from Sun:
> http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/tools.html
> Jeff
>
>
> -----Original Message-----
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
> Sent: Wednesday, September 16, 2009 9:04 AM
> To: Tomcat Users List
> Subject: RE: java.lang.OutOfMemoryError: PermGen space
>
> > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> > Subject: RE: java.lang.OutOfMemoryError: PermGen space
> >
> > You don't say if the JVM is 32-bit or 64-bit
>
> Actually, he did:
>
> > Architecture: amd64
> > JVM Version: 1.6.0_16-b01
> > JVM Vendor: Sun Microsystems Inc.
>
> The architecture would be x86 for a 32-bit JVM on Intel/AMD.
>
> > 1) By splitting the Heap in half between NewGen and PermGen
>
> This is not correct. The -Xmx size does not include the PermGen size.
>
> Again, use JConsole or equivalent to verify that the requested heap
> sizes are being used.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the
e-mail
> and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
> ******************************* NOTICE
> *********************************
> This message is intended for the use of the individual or entity to
> which
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law. If the
> reader of this message is not the intended recipient or the employee
or
> agent responsible for delivering this message to the intended
recipient,
>
> you are hereby notified that any dissemination, distribution, or
copying
>
> of this communication is strictly prohibited. If you have received
this
>
> communication in error, please notify us immediately by reply or by
> telephone (call us collect at 512-343-9100) and immediately delete
this
> message and all its attachments.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
> ******************************* NOTICE
*********************************
> This message is intended for the use of the individual or entity to
which
> it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law. If the
> reader of this message is not the intended recipient or the employee
or
> agent responsible for delivering this message to the intended
recipient,
> you are hereby notified that any dissemination, distribution, or
copying
> of this communication is strictly prohibited. If you have received
this
> communication in error, please notify us immediately by reply or by
> telephone (call us collect at 512-343-9100) and immediately delete
this
> message and all its attachments.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
******************************* NOTICE *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
