Positioning a memory leak

The first record of a memory leak location process


 

 

1. Memory leak found

  When deploying new code, and found a machine history data anomalies (from the usual memory footprint becomes a 4G 6G, JVM Memory in use grew from old's previous <1G, quickly increased to 2.5G), were not due peak alarm is triggered, the monitor does not receive in advance, be an unexpected discovery.

 

2. Machine unusual view

  First encountered this situation, in fact, is not sure what because, frequently youngGC, a huge increase network fluctuations in the same period also produced, they begin to see that time machine to do something, to see continue for some time network requests, but that does not have such a big impact. This time in the end disk usage also increased a lot, then go see where they come from 'File' on top of the machine. Found a new file called java.hprof on the machine, the size is 2.9G. After getting to know the log file is generated in a memory leak when, and learned that you can use to view the MAT (there are actually deal with memory leaks related to share heard before, but had forgotten, only to pick it up again, so is the driving force of this blog source)

 

3. MAT analysis java.hprof

  MAT download at: http: //www.eclipse.org/mat/downloads.php. The next step is to search for how to analyze hprof file. According to MAT prompts to locate abnormal reasons.

 

4. Summary

  The reason for this memory leak: the program generates a huge data (2.8G), greater than the threshold of the new generation of JVM, is stored in the old era.

Guess you like

Origin www.cnblogs.com/yishilin/p/11084077.html