About Tomcat Memory viewing

How Tomcat optimizes Java.lang.OutOfMemoryError:Java heap space solutions

Workaround for Java.lang.OutOfMemoryError:Java Heap space

Keyword: tomcat outofmemoryerror permgen space Java heap Space

Recently in the familiar with a project that has been developed for several years, the need to transfer the database from MySQL to Oracle, the first point of the JDBC connection to MySQL, packaged into Tomcat inside, can run, no problem, but when the JDBC connection point to Oracle, Tomcat on the continuous throw java.lang.OutOfMemoryError error, internet Google a bit, understand the operation of Tomcat, also solve the problem, share out, for reference.

1, the first is: Java.lang.OutOfMemoryError:Java heap space

Explanation:

Heap Size Setting

The JVM heap setting is the set of memory space that the JVM can provision during the run of the Java program. The JVM automatically sets the value of the heap size when it starts, and its initial space (that is,-XMS) is 1/64 of the physical memory, and the maximum space (-XMX) is 1/4 of the physical memory. You can use options such as the-XMN-XMS-XMX provided by the JVM to set it up. The size of Heap size is the sum of young Generation and tenured generaion.
Tip: This exception message is thrown in the JVM if 98% of the time is used for GC and the available heap size is less than 2%.
Tip: The Heap Size does not exceed 80% of the available physical memory, generally the-XMS and-XMX options are set to the same, and the-XMX value of-xmn is 1/4.

Workaround:

Manually setting the heap size
To modify the Tomcat_home/bin/catalina.bat, add the following line above the "echo" Using catalina_base: $CATALINA _base "":
Set java_opts=%java_opts%-server-xms800m-xmx800m-xx:maxnewsize=256m

or modify catalina.sh
Add the following line to the "echo" Using catalina_base: $CATALINA _base "":
java_opts= "$JAVA _opts-server-xms800m-xmx800m-xx:maxnewsize=256m"

2, followed by: Java.lang.OutOfMemoryError:PermGen space

Reason:

PermGen space is the full name of permanent Generation space, refers to the memory of the permanent storage area, this block of memory is mainly stored by the JVM class and meta information, class is loader will be placed in PermGen Space, unlike the heap area where the class instance (Instance) is stored, the GC (garbage Collection) does not clean up permgen space during the main program run time, so if you have a class in your application, PermGen space errors are most likely to occur when the Web server pre-compile the JSP. If you have a large number of third-party jars under your web app that are larger than the JVM's default size (4M), this error message will be generated.

Workaround:

1. Manually set the MaxPermSize size
Modify the Tomcat_home/bin/catalina.bat (under Linux for catalina.sh) and add the following line on the "echo" Using catalina_base: $CATALINA _base "":
Set java_opts=%java_opts%-server-xx:permsize=128m-xx:maxpermsize=512m

Under catalina.sh:
java_opts= "$JAVA _opts-server-xx:permsize=128m-xx:maxpermsize=512m"


In addition to see another post, feel very good, excerpt as follows:
Analysis Java.lang.OutOfMemoryError:PermGen Space

It is found that many people attribute the problem to: Spring,hibernate,tomcat because they dynamically produce classes that cause the permanent heap overflow in the JVM. Then there are a few opinions about how to upgrade the Tomcat version to the newest or even simply without Tomcat. There are also doubts about the spring issue, which is hotly debated on the Spring Forum, as spring uses cblib in AOP to generate many classes dynamically.

But the question is why the same problem arises from the open source of these trump cards, is it a more basic reason? Tomcat in Q&a very vague answer to this, we know this problem, but this problem is caused by a more basic problem.

Then someone checked the more basic JVM and found the key to the problem. It turns out that the Sun's JVM has divided the memory into different areas, one of which is the Permenter area used to store very many classes and class descriptions. Sun was designed to think the area was fixed when the JVM started, but he didn't expect it to be used so extensively. And this area has a special garbage recovery mechanism, now the problem is that the dynamic loading class to this area, the GC has no way to recycle!


For the above two questions, my handling is:

The first line in Catalina.bat is incremented:
Set java_opts=-xms64m-xmx256m-xx:permsize=128m-xx:maxnewsize=256m-xx:maxpermsize=256m

The first line in catalina.sh is incremented:
java_opts=-xms64m-xmx256m-xx:permsize=128m-xx:maxnewsize=256m-xx:maxpermsize=256m

~~~~~~~~~~~~~~~~~~~~~~~~

Command format jstat Command command format:

Jstat [Options] vmid [interval] [count]

Parameter description:

Options, option, we generally use-gcutil to view GC conditions
The VMID,VM process number, which is the currently running Java process number
Interval, interval, units of seconds or milliseconds
Count, number of prints, print countless times if default

Example of an express case

The following commands are typically run:

JSTAT-GC 12538 5000

That is, every 5 seconds, the process number 12538 is shown in the Java into the GC case,

Display content such as:

650) this.width=650; "Src=" http://img.blog.csdn.net/20150612150238390?watermark/2/text/ Ahr0cdovl2jsb2cuy3nkbi5uzxqvemx6bgvp/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity/center "/ >

Result description

The contents of the display are described below (some of the results are shown by other parameters and are not described):

S0C: Capacity of the first Survivor (Survivor area) in the Young Generation (bytes)
S1C: Capacity of the second survivor (Survivor area) in the younger generation (bytes)
S0U: The first survivor (Survivor area) of the young generation has currently used space (bytes)
S1U: The second survivor (Survivor area) of the young generation has currently used space (bytes)
EC: The Capacity of Eden (Eden) in the Young Generation (bytes)
EU: Eden (Eden) in the young generation has currently used space (bytes)
Capacity of the Oc:old generation (bytes)
Ou:old currently used space (bytes)
Pc:perm (persistent generation) capacity (bytes)
Pu:perm (persistent generation) currently used space (bytes)
YGC: Number of GC times in young generations from application startup to sampling
YGCT: The time taken by the GC in the young generation from application startup to sampling (s)
FGC: Old (full GC) GC count from application boot to sampling
FGCT: Time taken from an old (full GC) GC when the application boots to sampling (s)
GCT: GC Total time from Application boot to sample (s)
NGCMN: initial (minimum) size in Young generation (bytes)
NGCMX: Max capacity of young generation (bytes)
NGC: Current capacity in young generation (bytes)
The size (in bytes) of the initialization (minimum) in ogcmn:old generation
Maximum capacity of the Ogcmx:old generation (bytes)
The current newly generated capacity of the Ogc:old generation (bytes)
The size (in bytes) of the initialization (minimum) in pgcmn:perm generation
Maximum capacity of the Pgcmx:perm generation (bytes)
The current newly generated capacity of the Pgc:perm generation (bytes)
S0: The first survivor (Survivor area) of the young generation has been used as a percentage of current capacity
S1: The second survivor (Survivor area) in the younger generation has been used as a percentage of current capacity
E: Eden (Eden) in the young generation has been used as a percentage of current capacity
Percentage of current capacity used by O:old generation
Percentage of current capacity used by P:perm generation
S0CMX: Maximum Capacity (bytes) of the first Survivor (Survivor area) in the young generation
S1CMX: Maximum capacity of the second survivor (Survivor area) in the younger generation (bytes)
ECMX: Maximum capacity of Eden (Eden) in the Young Generation (bytes)
DSS: Capacity (bytes) currently required for Survivor (surviving area) (Eden area Full)
TT: Limited number of holds
MTT: Maximum number of hold limit

~~~~~~~~~~~~~~~~~~~

Jmap (Linux-specific, also a very common command)

Observe the physical memory usage of the JVM in operation.

The parameters are as follows:

-heap : Printing JVM Heap
-histo: Prints the histogram of the jvmheap. Its output information includes the class name, the number of objects, and the size of the object.
-histo:live : Same as above, but only promise to survive
-permstat: Print permanent generation heap condition

command to use:

Jmap-heap 3409

You can observe the memory usage of new Generation (Eden space,from space,to Space), Tenuredgeneration,perm Generation

Output content:

Jmap-histo 3409 | Jmap-histo:live 3409

You can observe the condition of all objects in the heap (in the case of all surviving objects in the heap). Includes the number of objects and the amount of space occupied.

Output content:

Write a script that can quickly find the object that is the largest in the heap, especially effective against memory leaks.

If you have a lot of results, you can use the following command to output to a text file.

Jmap-histo 3409 | Jmap-histo:live 3409 >a.txt

About Tomcat Memory viewing