A successful Memory Leak Analysis

Article Title: a successful Memory Leak analysis. Linux is a technology channel of the IT lab in China. Some basic classification systems, such as desktop applications, Linux system management, kernel research, embedded systems, and open-source systems, occasionally go down after they are launched, and each time they appear on the same two business points, after checking the code of the Program for multiple times and analyzing it carefully, the problem still persists. After the crash, the dump file and javacore file of G are generated, so the system has no analysis experience and has not found a solution to the problem for a long time. After searching for resources, we found two software, heapAnalyzer and jca. The former analyzes the dump file and the latter analyzes the javacore file. For heapAnalyzer, in windows, the dump file generated on AIX (for example, heapdump.2009052010992248.109562.phd) cannot be opened ), in addition, there is no such large memory available in the windows environment of the Local Machine to start the software. It is mandatory to directly use heapAnalyzer in the production environment. The file is successfully opened, but the analysis results are not readable. Non-WebLogic professionals may not be familiar with it. The general meaning is that a large number of objects are loaded somewhere in the program. As shown in: After using jca to analyze the javacore file, the solution is obtained. It turned out that we were using the J2RE 5.0 IBM J9 2.3 AIX ppc-32 build j9vmap3223-20070201 because of JDK problems. This SR4 version has a problem, the number of classes that can be loaded by the class loader is limited. The default value is 8192. If this limit is exceeded, an OutOfMemory error is thrown. Depressed, this is all happening. Analysis javacore: # cd/home
# Ls
Test. class guest nmon startVmstat. sh
Test. java heapAnalyzer ojdbc14.jar startWebLogic. out
Classes12.jar jca oracle startWebLogic. sh
Dumpfile jdk64_15 start. log stop. log
Esaadmin lost + found start. sh stop. sh
# Cd jca
# Ls
Jca. properties. xml license tdv. cfg
Jca37.jar readme.zip
# Java-Xmx1000m-jar jca37.jar In the analysis results Process ID , This should correspond to the execution process of the database server. If the time permits, we can Topas You can see that the process is being executed. At the same time, the analysis results are as follows: Current Thread, that is Corresponding to the Application Server thread that caused the error, use the thread name as the keyword in Log Search, we can find the cause of the error. Finally, Jca The suggestions after analysis are provided, Recommended-Xmxcl setting (only for IBM Java 5.0, up to and including Service Refresh 4 (build date: February 1st, 2007): 10,649 or greater .   Note: NOTE: Only for Java 5.0 Service Refresh 4 (build date: February 1st, 2007) and older. when you use delegated class loaders, the JVM can create a large number of ClassLoader objects. on IBM Java 5.0 Service Refresh 4 and older, the number of class loaders that are permitted is limited to 8192 by default and an OutOfMemoryError exception is thrown when this limit is exceeded. use the-Xmxcl parameter to increase the number of class loaders allowed to avoid this problem, for example to 25000, by setting-Xmxcl25000, until the problem is resolved.   After being depressed for a long time, the problem can be solved. Haha, I am in a good mood...