OutOfMemoryError

From Resin 3.0

(Difference between revisions)
Jump to: navigation, search
(OutOfMemoryError moved to Java.lang.OutOfMemoryError)
 
(migration)
Line 1: Line 1:
#redirect [[Java.lang.OutOfMemoryError]]
+
[[Category:Troubleshooting]]
 +
 
 +
Most memory problems are due to memory leaks in the application
 +
program.  For example, a cache or a vector that fills up with stale
 +
data, or a singleton or static variable which doesn't properly
 +
detect a web-app reload.  Some more exotic memory issues
 +
relate to running out of heap memory or virtual memory when using
 +
a large number of classes or threads.
 +
 
 +
== Troubleshooting steps ==
 +
 
 +
The steps to track down a memory problem are:
 +
 
 +
* Enable [[-verbosegc]].  The -verbosegc flag causing logging of the garbage collection of the heap, which will let you know if you're running out of heap memory (the most common case).
 +
* Get a heap profiler or use the heap dump in the JVM.  JProfiler is an inexpensive commercial heap profiler.  Although the JVM's heap dump is not very user friendly, it's always available.  Java developers should be using a heap profiler as part of the development process and before any production launch.
 +
* With the heap profiler, find the 2-3 top memory users and fix those memory leaks.
 +
 
 +
== Common application errors ==
 +
 
 +
Common application errors include:
 +
 
 +
* Singleton or static hash maps and caches, esp check for clearing web-app restarts.
 +
* Spawned threads which are not stopped on web-app restart.
 +
* web-app variables (like the "[[application (variable)]]" variable), stored in a static member of a class
 +
* [[ThreadLocal]] variables that are not properly cleared at the end of each request.  variable.
 +
 
 +
If the heap is clean (-verbosegc shows a steady heap), look at non-heap memory:
 +
 
 +
* JNI memory.  If you're using JNI libraries or drivers that use JNI, it's possible that the JNI can allocate more memory than is available.
 +
* fork/exec and OS limits.  If the OS does not have enough available swap space, for example, the OS might refuse a "jikes" compilation.
 +
* NIO, memory mapping, and .jar files.  The JDK memory-maps .jar files.  In some cases with very large numbers of jars, this can result in running out of virtual memory.  The same issue can appear for NIO memory mapping.
 +
 
 +
If all of these are eliminated, it might be a Resin bug.  However,
 +
you will need to have located the memory leak as Resin-related before
 +
any memory-related bug report, i.e. it's necessary to go through the
 +
above steps before reporting a bug.  Bug reports that complain
 +
about OutOfMemory errors, but have not even gotten a JDK memory
 +
dump are most likely application errors.  You must provide a
 +
heap dump when reporting any potential Resin memory problems.
 +
 
 +
== -verbosegc ==
 +
 
 +
{{main|-verbosegc}}
 +
 
 +
-verbosegc causes the JVM to output debugging information about garbage colleciton.  It is very convenient for checking basic memory usage and garbage collection time.  It's a good idea to use -verbosegc for any production system.  When starting Resin, you'll use -J-verbosegc.
 +
 
 +
The specific output depends on the JVM, and looks something like
 +
the following:
 +
 
 +
<!-- pre -->
 +
[GC 9176K->8647K(9768K), 0.0014790 secs]
 +
[GC 9287K->8668K(9768K), 0.0011120 secs]
 +
[GC 9308K->8668K(9768K), 0.0007810 secs]
 +
<!-- /pre -->
 +
 
 +
The "(9768K)" is the most important number, showing that the
 +
maximum allocated heap is about 10 meg.  The other numbers show the
 +
actual heap used before and after garbage collection.
 +
 
 +
== Heap dump ==
 +
 
 +
{{main|Heap dump}}
 +
 
 +
If an application gobbles up memory until it throws an OutOfMemory
 +
exception, or seems to be spending an excessive amount of time doing garbage
 +
collection, a heap dump can help track down the source of the problem.
 +
 
 +
== Types of memory ==
 +
 
 +
; Normal heap : The JVM heap size. Use [[-verbosegc]] to debug this.
 +
; Permanent heap :  An index into the heap for permanent objects such as classes.  Configured with [[-XX:MaxPermSize]].  The default is generally too small.
 +
; malloc() memory :  Used by JNI and in small parts by the JVM, does not show up as part of the JVM heap but should be shown by operating system tools.
 +
; mmap memory :  On Unix .jar files are mmapped taking up virtual memory. mmap memory does not show up as part of the JVM heap but should be shown by operating system tools.
 +
; Thread stacks :  Each thread has preallocated stack memory.  Resin [[httpd]] sets the stack size tpo a reasonable 1 meg unless an explicit value is provided on the [[command line]].
 +
 
 +
== See Also ==
 +
 
 +
; [[Garbage collection]] :

Revision as of 00:08, 21 February 2006


Most memory problems are due to memory leaks in the application program. For example, a cache or a vector that fills up with stale data, or a singleton or static variable which doesn't properly detect a web-app reload. Some more exotic memory issues relate to running out of heap memory or virtual memory when using a large number of classes or threads.

Contents

Troubleshooting steps

The steps to track down a memory problem are:

  • Enable -verbosegc. The -verbosegc flag causing logging of the garbage collection of the heap, which will let you know if you're running out of heap memory (the most common case).
  • Get a heap profiler or use the heap dump in the JVM. JProfiler is an inexpensive commercial heap profiler. Although the JVM's heap dump is not very user friendly, it's always available. Java developers should be using a heap profiler as part of the development process and before any production launch.
  • With the heap profiler, find the 2-3 top memory users and fix those memory leaks.

Common application errors

Common application errors include:

  • Singleton or static hash maps and caches, esp check for clearing web-app restarts.
  • Spawned threads which are not stopped on web-app restart.
  • web-app variables (like the "application (variable)" variable), stored in a static member of a class
  • ThreadLocal variables that are not properly cleared at the end of each request. variable.

If the heap is clean (-verbosegc shows a steady heap), look at non-heap memory:

  • JNI memory. If you're using JNI libraries or drivers that use JNI, it's possible that the JNI can allocate more memory than is available.
  • fork/exec and OS limits. If the OS does not have enough available swap space, for example, the OS might refuse a "jikes" compilation.
  • NIO, memory mapping, and .jar files. The JDK memory-maps .jar files. In some cases with very large numbers of jars, this can result in running out of virtual memory. The same issue can appear for NIO memory mapping.

If all of these are eliminated, it might be a Resin bug. However, you will need to have located the memory leak as Resin-related before any memory-related bug report, i.e. it's necessary to go through the above steps before reporting a bug. Bug reports that complain about OutOfMemory errors, but have not even gotten a JDK memory dump are most likely application errors. You must provide a heap dump when reporting any potential Resin memory problems.

-verbosegc

Main article: -verbosegc

-verbosegc causes the JVM to output debugging information about garbage colleciton. It is very convenient for checking basic memory usage and garbage collection time. It's a good idea to use -verbosegc for any production system. When starting Resin, you'll use -J-verbosegc.

The specific output depends on the JVM, and looks something like the following:

[GC 9176K->8647K(9768K), 0.0014790 secs]
[GC 9287K->8668K(9768K), 0.0011120 secs]
[GC 9308K->8668K(9768K), 0.0007810 secs]

The "(9768K)" is the most important number, showing that the maximum allocated heap is about 10 meg. The other numbers show the actual heap used before and after garbage collection.

Heap dump

Main article: Heap dump

If an application gobbles up memory until it throws an OutOfMemory exception, or seems to be spending an excessive amount of time doing garbage collection, a heap dump can help track down the source of the problem.

Types of memory

Normal heap 
The JVM heap size. Use -verbosegc to debug this.
Permanent heap 
An index into the heap for permanent objects such as classes. Configured with -XX:MaxPermSize. The default is generally too small.
malloc() memory 
Used by JNI and in small parts by the JVM, does not show up as part of the JVM heap but should be shown by operating system tools.
mmap memory 
On Unix .jar files are mmapped taking up virtual memory. mmap memory does not show up as part of the JVM heap but should be shown by operating system tools.
Thread stacks 
Each thread has preallocated stack memory. Resin httpd sets the stack size tpo a reasonable 1 meg unless an explicit value is provided on the command line.

See Also

Garbage collection 
Personal tools