Java.lang.OutOfMemoryError:Map Failed Summary

The common Oom is the following:
1.GC Overhead limit exceeded
2.Java Heap Space
3.Unable to create new native thread
4.PermGen Space
5.Direct Buffer Memory
6.request {} bytes for {}. Out of swap space?
Always think that there will not be more than this range of Oom type appeared, did not expect to see a new type of oom recently, and this time oom caused a serious failure, the entire process is a colleague in the internal troubleshooting, the article is he wrote, thank him for the article, Let me also learn about an oom-related knowledge point that I missed before.

The fault phenomenon is
A large number of oom exceptions were found in the Application log:
Caused By:java.lang.OutOfMemoryError:Map failed

The trace stack found to throw an exception is in the Filechannle#map, this method is to create a memory map file, the application in order to reduce the use of heap memory, while improving the efficiency of writing, a file into multiple segments, memory mapped multiple mappedbytebuffer for read and write operations;

The method of tracking Filechannle.map found that the final call is the method in FILECHANNELIMPL.C;

Continue to trace this code, found inside called Mmap64 this system function, when the MMAP64 return error code is ENOMEM, will throw up Oome, further consult the GNU Manual, you can find the explanation of the Enomem error code thrown:
1. Insufficient memory;
2. Insufficient address space.

And from the scene of the information at the time, the two points are not established, there is no new ideas, so first according to the Filechannleimpl.unmap method in the active release of the method of memory to change the code, changed after the application of all normal.

The same day the JVM of this machine also crash once, crash log in the heap occupies and physical memory are very normal, but there is a phenomenon in the log is very strange: Dynamic libraries: This part of the information is very much, statistics found that there are 65,532.

Flip through the data, found that the information from/proc/{pid}/maps, this file shows the process of virtual address space usage, then suddenly think of enomem in the process of the address space is not enough to cause, but the final 7fff005aa000 is far from the upper limit, and computing virtual memory occupies a few grams of space.
At this time think of the previous mention of 65532 this data, Lenovo to the File-max, but a view is 4889494, the homeopathic guess virtual memory mapping is also open upper limit? As expected, there is a limit.

Max_map_count This parameter is to allow a process to have the maximum number of VMAs (virtual memory area), VMA is a contiguous virtual address space, when the process creates a memory image file, the VMA address space will increase when the MAX_MAP_ is reached Count is the return out of the memory errors.
This data can be viewed by the following command:
Cat/proc/sys/vm/max_map_count

The value of the machine where the application is found is 65536, and the upper limit of the number of Filechannel#map after the test has changed max_map_count. So you can determine that the program Oom is due to reach the upper limit of the system, that is, the ENOMEM error code refers to the out of process address.

Determine the cause of the exception, and then to troubleshoot the cause is easier, and then look at the Filechannleimp#map code, found in the first time when the map of Oom, will be explicitly called System.GC to reclaim, but unfortunately the application startup parameters are-xx:+ DISABLEEXPLICITGC, so it causes the map to fail, but if the active clean in the code is OK phenomenon.

In summary, this anomaly occurs because:
Data volume growth, resulting in the number of map file growth, application startup parameters have-XX:+DISABLEEXPLICITGC, resulting in the map file number reached Max_map_count after the direct oom (this is because the heap is larger, so the full The frequency of GC triggering is low, and this problem is particularly susceptible to exposure.

From this point of view, the start parameter plus-XX:+DISABLEEXPLICITGC really still have to be careful, not only map file here is after the Oom by explicit to perform system.gc to recover, Direct Bytebuffer is actually the case, And these two scenarios are possible because the Java itself full GC execution is infrequent, resulting in the constraints (such as the number of map file reached Max_map_count, and direct bytebuffer to Maxdirectmemorysize), So in the case of CMS GC, it seems to be removed this parameter, instead of adding-xx:+explicitgcinvokesconcurrent this parameter more secure.

Java.lang.OutOfMemoryError:Map Failed Summary