Error Java.Lang.Outofmemoryerror: Gc Overhead Limit Exceeded

Error java.lang.OutOfMemoryError: GC overhead limit exceeded

This message means that for some reason the garbage collector is taking an excessive amount of time (by default 98% of all CPU time of the process) and recovers very little memory in each run (by default 2% of the heap).

This effectively means that your program stops doing any progress and is busy running only the garbage collection at all time.

To prevent your application from soaking up CPU time without getting anything done, the JVM throws this Error so that you have a chance of diagnosing the problem.

The rare cases where I've seen this happen is where some code was creating tons of temporary objects and tons of weakly-referenced objects in an already very memory-constrained environment.

Check out the Java GC tuning guide, which is available for various Java versions and contains sections about this specific problem:

Java 11 tuning guide has dedicated sections on excessive GC for different garbage collectors:
- for the Parallel Collector
- for the Concurrent Mark Sweep (CMS) Collector
- there is no mention of this specific error condition for the Garbage First (G1) collector.
Java 8 tuning guide and its Excessive GC section
Java 6 tuning guide and its Excessive GC section.

Spring Boot application- problem with java.lang.OutOfMemoryError: GC overhead limit exceeded

My SpringBoot app have a problem with java.lang.OutOfMemoryError: GC overhead limit exceeded.
I can see log as below:
Handler dispatch failed; nested exception is 
java.lang.OutOfMemoryError: GC overhead limit exceeded. 

That is a common error.

It means that your application's JVM is spending too much time running the garbage collector. It typically happens because you have nearly run out of space, and the GC is having to run more and more often to keep going.

Additionally, cpu is very high when I working in the application(99%).

That is to be expected; see above.

I think that it is connected with xmx.

Yes it is connected with that.

One possibility is that the task your webapp is doing needs needs more memory than is allowed by the -xmx setting. Increasing -xmx will solve the problem ... until you get to a larger task. At that point you need to see if you can optimize memory usage, or buy a machine with more memory. (How much money do you have in the bank?)

Another possibility is that your webapp has a memory leak. If that is the problem then increasing -xmx doesn't solve the problem. Your webapp is liable to run into OOME's again ... though it may take longer for it to happen.

I suggest that you find and read a good article on fixing memory leaks. Assume that it is a leak ... until you find clear evidence that it is not.

So how can I check the xmx size set for this application?

It depends on how you are running the springboot application. For example, this article explains how to do it with an embedded Tomcat.

How can I configure the heap size when starting a Spring Boot application with embedded Tomcat?

java.lang.OutOfMemoryError: GC overhead limit exceeded

You're essentially running out of memory to run the process smoothly. Options that come to mind:

Specify more memory like you mentioned, try something in between like -Xmx512m first
Work with smaller batches of HashMap objects to process at once if possible
If you have a lot of duplicate strings, use String.intern() on them before putting them into the HashMap
Use the HashMap(int initialCapacity, float loadFactor) constructor to tune for your case

PySpark error java.lang.OutOfMemoryError: GC overhead limit exceeded

Taking straight from the docs,

The first step in GC tuning is to collect statistics on how frequently garbage collection occurs and the amount of time spent GC. This can be done by adding -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps to the Java options.
The goal of GC tuning in Spark is to ensure that only long-lived RDDs are stored in the Old generation and that the Young generation is sufficiently sized to store short-lived objects. This will help avoid full GCs to collect temporary objects created during task execution.
Check if there are too many garbage collections by collecting GC stats. If a full GC is invoked multiple times for before a task completes, it means that there isn’t enough memory available for executing tasks.
If there are too many minor collections but not many major GCs, allocating more memory for Eden would help. You can set the size of the Eden to be an over-estimate of how much memory each task will need. If the size of Eden is determined to be E, then you can set the size of the Young generation using the option -Xmn=4/3*E. (The scaling up by 4/3 is to account for space used by survivor regions as well.)
In the GC stats that are printed, if the OldGen is close to being full, reduce the amount of memory used for caching by lowering spark.memory.fraction; it is better to cache fewer objects than to slow down task execution. Alternatively, consider decreasing the size of the Young generation. This means lowering -Xmn if you’ve set it as above. If not, try changing the value of the JVM’s NewRatio parameter. Many JVMs default this to 2, meaning that the Old generation occupies 2/3 of the heap. It should be large enough such that this fraction exceeds spark.memory.fraction.
Try the G1GC garbage collector with -XX:+UseG1GC. It can improve performance in some situations where garbage collection is a bottleneck. (This helped me)

Some more parameters that helped me were,

-XX:ConcGCThreads=20
-XX:InitiatingHeapOcuupancyPercent=35

All GC tuning flags for executors can be specified by setting spark.executor.extraJavaOptions in a job’s configuration.

Check this out for further details.

EDIT:

In you spark-defaults.conf write,

spark.executor.JavaOptions -XX:+UseG1GC

spark.executor.extraJavaOptions -XX:ConcGCThreads=20
-XX:InitiatingHeapOcuupancyPercent=35