Re: OutOfMemoryError PermGen Space...
On 22/07/10 21:53, James Carman wrote: I'm running Tomcat, so it's: $ env | grep CATALINA CATALINA_OPTS= -Xmx4096m -Xms2048m -XX:MaxPermSize=1024m -XX:+UseParallelGC -server Well, if you have increased memory for the permanent generation several times and keep seeing this error, for me this sounds like a memory leak. Tuning the java garbage collection will in all cases not help here, because java only throws an out of memory error if garbage collection does not help any more. I would enable the following for tomcat: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/java/whatever Then you can analyse what holds all the memory after the next crash. A nice tool for that is the Eclipse Memory Analyzer: http://www.eclipse.org/mat/ A little how to for getting started: http://wiki.eclipse.org/index.php/MemoryAnalyzer And you should search what they have at the tomcat pages and on their mailing list archives: http://wiki.apache.org/tomcat/OutOfMemory This is most likely not specific to wicket itself. Andreas On Thu, Jul 22, 2010 at 3:47 PM, david_ meulemans.da...@gmail.com wrote: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.htmlthese are my settings set JAVA_OPTS=%JAVA_OPTS% -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m 2010/7/22 James Carman [via Apache Wicket] ml-node+2299232-642663496-232...@n4.nabble.comml-node%2b2299232-642663496-232...@n4.nabble.com Of course. It's set at 1024m! I bumped it from 256 to 512 to 1024 now. I'm still seeing the error. On Thu, Jul 22, 2010 at 3:31 PM, Martin Makundi [hidden email] http://user/SendEmail.jtp?type=nodenode=2299232i=0 wrote: You did try to change your permgen setting? http://rimuhosting.com/knowledgebase/linux/java/-Xmx-settings ** Martin 2010/7/22 James Carman [hidden email]http://user/SendEmail.jtp?type=nodenode=2299232i=1: Oops! I must not have copied that line. All it said was PermGen space On Thu, Jul 22, 2010 at 3:25 PM, Martin Makundi [hidden email] http://user/SendEmail.jtp?type=nodenode=2299232i=2 wrote: Where is the outofmemoryerror ? ** Martin 2010/7/22 James Carman [hidden email]http://user/SendEmail.jtp?type=nodenode=2299232i=3: I'm running Wicket 1.4.9 and Sun's JDK 1.6.0_20 on a RHEL4 64-bit machine. On Thu, Jul 22, 2010 at 2:30 PM, James Carman [hidden email]http://user/SendEmail.jtp?type=nodenode=2299232i=4 wrote: Guys, our production server is running into an error from time to time. I get the below stack trace after the site has been running for a while. It's not running in development mode. It's running in deployment mode. Any thoughts? What's with this generateSerializationConstructor() stuff? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OutOfMemoryError PermGen Space...
On 23/07/10 10:19, Johan Compagner wrote:
i think the problem with those memory analyzers that they give you the heap
Not the non heap, which is currently the problem..
Yes, but they are the only thing you have if you do not use a profiler
to look at the running app.
And since the permanent generation does not grow on it's own without any
link to the heap, you can find the reason for the problem this way with
a little luck.
If really constantly classes are leaked without that you constantly
redeploy web applications (because that would be a leak somewhere in
wicket or the app itself)
It can be a problem in any library that you use and that are generally
quite many these days...
I had similar problems with database drivers and object mapping libs,
but you are right, in this case the problem normally arises with
redeployments of the app without restart of the container.
http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/
but the only thing you do is serializing these kind of objects:
You may be right with your analysis of the serialization, I just want to
note here that in case of an out of memory error the stack trace can be
completely irrelevant. It just shows at what step the memory was full,
but that step does not have to be the cause for the memory filling up.
// not serializeable and doesnt have a default constructor
public class A {
String name;
// add this constructor so the compiler doesnt generate a default one.
public A(String name) {
this.name = name;
}
}
public class B extends A implements Serializable {
int aNumber;
public B() {
super(B);
aNumber = 10;
}
}
If you then serialize instances of B then i think you will come into
the section of the stacktrace James gave.
But this shouldnt really leak into the none heap. (and result in an
never ending grow) that would just a bug in java itself if you ask me.
i think the work around is to give the A class a private constructor:
private A() {}
Then i think nothing is tried to be generated.
2010/7/23 Andreas Prieß a...@metaphysis.net:
On 22/07/10 21:53, James Carman wrote:
I'm running Tomcat, so it's:
$ env | grep CATALINA
CATALINA_OPTS= -Xmx4096m -Xms2048m -XX:MaxPermSize=1024m
-XX:+UseParallelGC -server
Well, if you have increased memory for the permanent generation several
times and keep seeing this error, for me this sounds like a memory leak.
Tuning the java garbage collection will in all cases not help here,
because java only throws an out of memory error if garbage collection
does not help any more.
I would enable the following for tomcat:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/java/whatever
Then you can analyse what holds all the memory after the next crash.
A nice tool for that is the Eclipse Memory Analyzer:
http://www.eclipse.org/mat/
A little how to for getting started:
http://wiki.eclipse.org/index.php/MemoryAnalyzer
And you should search what they have at the tomcat pages and on their
mailing list archives:
http://wiki.apache.org/tomcat/OutOfMemory
This is most likely not specific to wicket itself.
Andreas
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
