TOMCAT/JVM performance Optimization (also PermGen troubleshooting)

A recent SSH2 project upgraded the framework, and after deployment it was discovered that execution was inaccessible for a period of time (Tomcat and other Web Access is normal).

MyEclipse "stress test" times wrong: Exception in thread "com.mchange.v2.async.threadpoolasynchronousrunner$poolthread-#0" Java.lang.OutOfMemoryError:PermGen Space

The subsequent phenomenon is similar to the one deployed on the test machine, and the initial judgment is the reason. Combined with this exception, the underlying reason may be that the framework of the third party jar package, class file occupancy is larger, on the other hand, some modules request historical data over time will return more JSON data, stored in the member of the action string variable, Back to the front end through the struts framework, which is exactly what is stored in the permanent generation (PermGen). There is also a test deployment that occurs when exception loading sessions from persistent storage

Java.io.WriteAbortedException:writing aborted; Java.io.NotSerializableException: ... The solution at that time was for the corresponding bean to inherit the serializable interface while the work/catalina/localhost/project folder was deleted. It is well known that this is the directory of JSP compiled file storage, and PermGen OutOfMemoryError is easy to happen when the Web server pre-compile the JSP. To sum up, then first look at the allocation of PermGen the use of it.

Jstat Memory Monitoring (http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstat.html):

For example, view permgen:jstat-gcpermcapacity PID

View processes on Windows: tasklist | Findstr Javaw.exe

Jstat memory Monitor appears pid not found:

Jstat pid not found occurs when viewing PermGen on a deployed project on the server. The basic principle of jstat is to generate a hsperfdata_username directory (which contains PID files, log process information), by default in the Java.io.tmpdir directory (the default is/tmp on Linux), But when I execute jstat, there is no PID file in this directory. And the online information said JDK1.6.0.23/24 version compatibility issues, and I just used 0.23, stepped on the pit.

While it's true that 6u23/24 introduce this issue, it's not a bug in JPS. Rather a change in behavior of the VM itself. On Gnu/linux Jps and the likes seem to only look at/tmp is not necessarily your catalina_tmpdir. If set or not, try to export catalina_tmpdir=/tmp which translates to '-djava.io.tmpdir=/tmp ' and after restarting the Tom Cat process should see Tomcat ' s data as "/tmp/hsperfdata_/" and Jps would most likely work again as well.

The workaround is to modify the VM configuration file, in tomcat/bin/catalina.sh, find Catalina_tmpdir, change to Catalina_tmpdir=/tmp, reboot Tomcat.

Continued local "Stress test", the result of a problem, PermGen pgc/pc has been consumed by light, YGC/FGC the number of times climbing, while the FGCT/GCT also continue to increase, it is clear that the JVM attempts to continue to do GC attempts to release PermGen, but seems to be powerless, Causes the program to remain blocked. Well, change the PermGen parameter slightly.

To change the JVM PermGen parameters for Tomcat:

Because it is the local myeclipse to start Tomcat in debug mode, it is added after execute the requested command in%catalina_home%/bin/catalina.bat in accordance with the online method. After set java_opts=%java_opts%-server-xx:permsize=128m-xx:maxpermsize=256m, debug startup is invalid, In fact, this time Tomcat is called Tomcat7.exe boot, so the parameters in the Catalina.bat can not be effective.

The correct way is to add the optional Java VM arguments to the JDK, Tomcat---x.x, Servers, MyEclipse-i-Preferences

-xx:permsize=128m

-xx:maxpermsize=256m

Start again.

originally PermSize set to 64m,web project start execution process, if not enough when it will be in some way incremental allocation, such as FGC, PGC/PC to 140M, the next will be FGC in time, and reduced to 135M,130M and so on . So much tired ah, rather than the initial allocation of a little more, allocate 128M, and then test, the implementation of the observation process did not occur FGC.

That's it? In fact, I also want to optimize from the code to improve memory utilization, to eliminate possible memory leaks and other issues. But the old code too much (the problem is the upgrade process, most of the code is not moved, but only a few new modules), it is suspected that the SSH framework (Spring3.2.1, Struts2.3.4, Hibernate3.3.2) problems. In this respect, we have experience, please give us more advice. Usually focus on business, there is no time to dig up technical details ...

TOMCAT/JVM performance Optimization (also PermGen troubleshooting)