If you think you will never run into out of Memory error because your code is leak proof and your application server is rock solid, think again. Your application can run out of what eludes most developers and Systems Administrators – Native memory.
To put it blunt, Native memory is the memory used by JVM itself for its internal low-level tasks (for example file handles) and the memory used by any native code (such as a C library within the JVM).
What are the symptoms of native memory issues?
1. Unexpected application errors
2. One of the following error message in the log file
a. java.lang.OutOfMemoryError:Detail Message: request <size> bytes for <reason>. Out of swap space?
b. java.lang.OutOfMemoryError:Detail Message: <reason> <stack trace> (Native method)
Note that the errors above are for Oracle HotSpot. The error varies by the JVM vendor.
What causes native memory issue?
Note that the JVM is just a process as far as OS is concerned and hence it is subject to all resource restrictions that the OS poses. Here are some of the major causes of native memory issues
1. Application code issue where fault code creates tons of low level elements (such as File handles,network sockets etc).
2. Third party library code issue (for example C libraries) that suffer from memory leaks
How to prevent native memory issue?
There is not a lot you can do to prevent a native memory issue as these issues are totally unexpected.
But you can try the following
1. Ensure the third party native libraries you use are correct versions and for the appropriate OS and architecture
2. Ensure the application code does not leave lingering network or file handles.
One useful way to determine if you have native memory issue is to check the ‘process size’ of the JVM viewed using operation system tools (for example ‘top’ in Unix). This process size will include Heap and native memory used.
Moving on, let us explore various troubleshooting tools available to aid you with Memory issues
Coming up: Troubleshooting GC: Using Verbose GC logs