This is a log when I investigated an application that was killed by OOM Killer due to lack of memory in the JVM. I used GC Viewer to check the GC log file to see the transition of memory usage.
Before that, I also reorganized the outline of Java memory management, so I have described it.
A prerequisite knowledge of Java memory management is required to view GC Viewer.
This article was very helpful. Thank you very much. http://qiita.com/opengl-8080/items/64152ee9965441f7667b
A very rough diagram showing the memory structure. Largely, there are two areas, a heap area and a native area. The heap is an area used by Java programs, and objects created on the program are placed in this heap area. On the other hand, the native area is used to manage the stack of memory and threads needed for the JVM to run.
(Source: http://qiita.com/opengl-8080/items/64152ee9965441f7667b#java-%E3%81%AE%E3%83%A1%E3%83%A2%E3%83%AA%E7%AE% A1% E7% 90% 86)
From the above, you can see that there are Young (New) and Old (Tenurd) in the heap.
The flow of GC seems to be as follows.
--The newly created object is saved in the Eden area of the Young area. --When Eden is full, the GC in the New area (called Scavenger GC, which is executed frequently) runs, and the objects that are not destroyed here are moved from Eden to the Survivor area. --The next time the Scavenger GC runs, the movement from Eden to Survivor is the same, and objects that were in the Survivor area that were not destroyed are moved to the other Survivor area. --Repeat this, and when the number of transfers exceeds the threshold, the object will be moved to the Old area. --Full GC runs when the Old area is full, but this takes a long time to process, so this number should be reduced.
http://qiita.com/taisho6339/items/a6a7954bd473e16706bd http://blog.pepese.com/entry/20120508/1336467306 http://www.whitemark.co.jp/tec/java/javagc.html
https://github.com/chewiebug/GCViewer/wiki/Changelog The above is the URL for downloading the application.
Simply open the downloaded application and drag and drop the GC log file. It was easy.
At first, many lines and areas are displayed, but I narrowed down to only the necessary ones from the View settings. The displayed area and destination are as follows.
--Pink is the Old area --Yellow is the Young area --The pink line inside the pink is the heap usage of the Old area. --The gray line in yellow is the heap usage of the New area. --The blue line is the total heap area usage --The black line is when FullGC runs
From the above, it can be inferred that OOM Killer ran due to lack of memory in the area where the black lines on the far right are dense.
This is the output of GC Viewer after increasing the memory.
It was stable.
that's all.
Recommended Posts