How to check oom

  • JVM memory model and garbage collection mechanism
  • How to obtain and analyze OOM information and GC logs
  • Analytical tools

Command used to print information

  • -xx :+PrintCommandLineFlags: Prints the garbage collector used
  • -xx :+PrintHeapAtGC: Prints heap usage
  • – XX: AdaptiveSizePolicyOutputInterval = 1: Scavange collector automatically adjust the heap size parameters, such as printing parameter changes
  • -xx :+PrintGCDetails: Prints GC logs
  • -xx :+PrintGCTimeStamps: Prints the time taken by GC
  • -xmx3m: Sets the heap size
  • – XX: + HeapDumpOnOutOfMemoryError: when oom that create the dump file

GC Log Reading

Heap information

-xx :+PrintHeapAtGC makes it easier to read

PSYoungGen total 1536K, used 1024K [0x00000007bfe00000, 0x00000007c0000000, 0x00000007c0000000) eden space 1024K, 100%, informs [x00000007bfe00000 0, 0 x00000007bff00000, 0 x00000007bff00000) from space 512 k, 0%, informs [x00000007c0000000 x00000007bff80000 0, 0 x0000007bff80000, 0) to space 512 k, 0%, informs [x00000007bff00000 0, 0 x00000007bff00000, 0 x00000007bff80000) ParOldGen total 4096 k, 2 0 k [0 x00000007bfa00000, 0x00000007bfe00000, 0x00000007bfe00000) object space 4096K, 0%, informs [x00000007bfa00000 0, 0 x00000007bfa00000, 0 x00000007bfe00000) Metaspace informs the 2594 k, capacity 4494 k, committed 4864K, reserved 1056768K class space used 286K, capacity 386K, committed 512K, reserved 1048576KCopy the code

GC

Refer to the blog

0.159: [Allocation Failure (GC) [PSYoungGen: 1024K->432K(1536K)] 1024K->432K(5632K), 0.0006879 secs] [Times: User sys = = 0.00 0.00, real = 0.00 secs]Copy the code
  • 0.159Is the current time
  • GC is the type of GC, and this represents Young GC
  • (Allocation Failure) is the cause of GC

GC (Allocation Failure)

Young GC, which is basically an Allocation Failure

Full GC (Allocation Failure)

Before young GC, it will check whether the remaining continuous space of the old age is larger than the size of all objects of the new generation, and then check whether it is larger than the average size of surviving objects. If not, full GC will be performed

Full GC (Ergonomics)

Garbage Collector Ergonomics This is the case when collectors using the Paralle Scavange Collector and JVMS such as CMS adjust parameters to achieve goals such as pause times and throughput. If you turn off the adaptive policy (-xx: -useadaptivesizePolicy =false), you lose the ability to adjust pause times and throughput.

Adaptive Policy

UseAdaptiveSizePolicy actions to meet *** throughput goal ***

GC overhead (%) Young generation: 10.43 (Runtime to grow) Tenured Generation: 84.65 (CHS to grow) Tenuring Threshold: (CHS to decrease to avoid survivor space overflow) = 3Copy the code

Attempt to Grow means to reach the target, the space can be larger, but if the maximum heap size has been set, there is no way to change it.

Error message

A full explanation can be found in the official documentation

Java heap space

The heap space is insufficient. This error is thrown when there is no space after Full GC (Allocation Failure)

Possible causes

  • The heap space is set too small
  • A memory leak

GC Overhead limit exceeded

Means that garbage collection takes up too much time but is not productive, which means that five consecutive garbage collections take up 98% of the time but clean up less than 2% of the space.

Parallel Scavange adjusts JVM parameters to meet the set pause times and throughput goals, and if the last garbage collection was not met, the next will be Full GC (Ergonomics).

Gc overhead is usually caused by continuous Full GC (Ergonomics)

Requested array size exceeds VM limit

The size of the array exceeds the heap size

Analysis tools

Gc log + Visual VM + dump file

The screening process

The first and second cases above are mainly encountered for two reasons: heap size is too small or memory leak

  • View error messages
  • If you open a dump file with a VM, the VM will tell you the amount of space that the object occupies. If you have an object that occupies a lot of space, you will almost certainly be leaking it
  • If you can’t see where these objects were generated, look at the references
  • If there is no Leak, the heap might not be large enough