Tag Archives: JVM

[Solved] JVM Error: Failed to write core dump. Core dumps have been disabled.(jar was Forced to Exit)

JVM reports an error: failed to write core dump. Core dumps have been disabled

In the high concurrency big data scenario, the Linux server reports an error fork: retry: the resource is temporarily unavailable
the JVM will generate an HS_err_Pid74299.log log log files like this

By default, the core file size of the Linux service is set to 0. This parameter needs to be adjusted, but this parameter does not solve the problem;

The root cause of the problem is that the maximum number of open files and the maximum number of processes of the running application of the server are relatively small, and the default is 4096

The following configuration needs to be modified:

vi /etc/security/limits.conf

* soft nofile 327680
* hard nofile 327680
hdfs soft nproc 131072
hdfs hard nproc 131072
mapred soft nproc 131072
mapred hard nproc 131072
hbase soft nproc 131072
hbase hard nproc 131072
zookeeper soft nproc 131072
zookeeper hard nproc 131072
hive soft nproc 131072
hive hard nproc 131072
root soft nproc 131072
root hard nproc 131072

Record a JVM memory overflow java.lang.outofmemoryerror: GC overhead limit exceeded

Open source software supply chain lighting plan, waiting for you>>>

Error log information

java.lang.OutOfMemoryError: GC overhead limit exceeded
2020-06-16 10:44:22.004 [http-nio-8083-exec-91] ERROR o.a.c.core.ContainerBase.[Tomcat].[localhost] - Exception Processing ErrorPage[errorCode=0, location=/error]
org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1061)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:942)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1005)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:897)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
        at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:882)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:712)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:461)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:384)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312)
        at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:394)
        at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:253)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded

Cause of the problem

Use the PS command to find out the running PID of the jar, and then check the details of the Java heap. It is found that the memory is 99%

Reason 1: the initial memory configuration is really too small

Reason 2: related code logic problems lead to memory overflow

jmap -heap PID 

Problem solving

Here is to increase the heap size for the time being

-Xmx4000m -Xms4000m

After adjustment:

Summary

focus on code logic problems. If it’s a code problem, adding heap memory can only delay the generation of java.lang.outofmemoryerror, and eventually lead to memory overflow

JVM parameters

There are three types of JVM startup parameters

Standard parameters (-). All JVM implementations must implement the functions of these parameters and be backward compatible

The non-standard parameter (- x) refers to some configuration parameters at the bottom of the JVM. These parameters can be used by default in general development without any configuration. However, in the production environment, it is not guaranteed that all the JVM implementations are satisfied, so in order to improve the performance, it is often necessary to adjust these parameters in order to achieve the best performance of the system. In addition, these parameters do not guarantee backward compatibility, that is to say, “if there is any change, we will not notify the subsequent version of JDK” (this is the original words on the official website)

Non stable parameter (- XX). This kind of parameter is unstable in the JVM and is not suitable for daily use. In the future, it may be cancelled directly without notice, so it needs to be used carefully

Three main domains of JVM memory

There are three main domains: new domain, old domain and permanent domain
all new objects generated by the JVM are placed in the new domain once an object goes through a certain number of garbage collection cycles, it enters the old domain. The persistent domain is used to store the reflection objects of the JVM itself, such as class and method objects, and GC (garbage collection) will not clean up the persistent domain during the main program runtime (main reason). The new domain and the old domain belong to the heap, and the permanent domain is an independent domain and is not considered a part of the heap

function of main parameters

– XMS: sets the initial size of the JVM memory

– Xmx: sets the maximum memory of the JVM

– XMN: set the size of the new domain (this seems to work only for jdk1.4, but it was abandoned later)

– XSS: set the stack size of each thread (that is, in the same physical memory, reducing this value can generate more threads)

– XX: newratio: set the ratio of the new domain to the old domain. For example, – XX: newratio = 4 means that the ratio of the new domain to the old domain is 1:4

– XX: newsize: sets the initial value of the new domain

– XX: maxnewsize: sets the maximum value of the new domain

– XX: permsize: sets the initial value of the persistent field

– XX: maxpermsize: sets the maximum value of the persistent field

– XX: survivorratio = n: set the ratio of Eden area and two survivorregions in the new domain( Eden area is mainly used to store new objects, while the two survivor areas are used to store objects that survive each garbage collection.)

After the JVM is started, setting the system property file.encoding again cannot affect the default encoding of the system & sun.jnu.encoding

Causes and solutions:

https://bugs.java.com/bugdatabase/view_ bug.do?bug_ id=4163515

https://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding/362006#362006

Who sets file. Encoding

First, file. Encoding is a system property. It can be set before starting the JVM, such as:

  java -Dfile.encoding=UTF-8 xxx.class

Another way is to change the system region of the operating system, because if this property is not set when the JVM starts, the encoding mode is selected according to the system region (locale) by default

When the region is China, the file.encoding is GBK region

When the region is the United States, the file.encoding is cp1252 region

  

In JDK1.8, only four references to file. Encoding are found

The default encoding method of JVM: charset. Defaultcharset ()

Function of sun.jnu.encoding: used to parse command line parameters, classes containing main methods, and environment variables

http://happygiraffe.net/blog/2009/09/24/java-platform-encoding/