When doing server-side development, it is often encountered that the service hangs due to memory overflow. Generally speaking, the occurrence of this situation is difficult to predict and difficult to reproduce. For this kind of problem, it can generally be recorded by recording Heap information when memory overflows to check.
1. First, you can view the server operation log and the log recorded by the project, and catch the memory overflow exception.
2. If the program hangs, but no log records for this operation are found. At this point take a look at the /var/log/messages file. The messages log is the core system log file. It contains boot messages when the system starts, and other status messages when the system is running. The following information will appear in the messages:
figure 1
The reason for this is that both the server and the project log can only record memory overflows that occur within the JVM, which means that the size of the heap exceeds the size set by the JVM. However, if the heap size set by the JVM exceeds the memory size allowed by the operating system, the operating system will kill the process directly, in which case the JVM cannot record this operation.
It can be seen from Figure 1 that the operating system directly kills the process with the highest rating due to the high memory usage, here is the java process. Linux has an OOM score for each process, which is in the /proc/pid/oom_score file. For example /proc/8398/oom_score, if you do not want to kill this process, change the content of oom_adj to -17.
3. In this case, you first need to adjust the heap size of the JVM and set it in the running parameters
-Xms20m -Xmx20m
Make the heap smaller so that the OOM of the JVM takes precedence over the OOM of the operating system. Then set the running parameters, and output the heapdump file when OOM occurs.
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/home/admin/logs/java.hprof
4. When an OOM exception is captured, a java.hprof file will be generated.
The article is excerpted from: http://blog.csdn.net/u010256841/article/details/41121755