Below points we can check for Garbage Collection error’s and their reasons.
Overview:
The virtual machine garbage collection (GC) can be executed at any time so the symptoms can be various, such as:
poor performance
AS Java crashes with exit code 33x.
AS Java startup fails
AS Java restarts
deploy hangs or fails
web request hangs
Reason:
The root cause is usually one of the following:
OS paging:
During a full GC, unreferenced old objects are cleaned up from the heap. On the other side, the OS divides the memory in spaces called pages.
The pages which are not recently used are swapped down on a disk.
So if the VM access old unreferenced object, the probability to access a swapped page is huge.
Access of swapped down memory page is considered as “fault” and the number of faults is a metric for GC performance (column ‘pagefaults’ in MMC).
Since a page fault is a time consuming operation, the number of page faults is crucial for GC performance.
The Operating System’s (OS) mechanism for providing free main memory by temporarily storing portions (“pages”) of it on hard disks is called “swapping” or “paging”. Copying pages back from disk (the “swap space”) to main memory can take a significant amount of time, considerably exceeding main memory access times.
When the CPU tries to access a swapped-out page, a so-called “page fault” occurs, causing the CPU to wait for the page to be copied back from disk to main memory.
The SAP JVM’s old generation garbage collection procedure needs to walk through the entire Java heap, thus touching every single memory page allocated to the heap. A high number of swapped-out pages drastically slows down this procedure.
In the worst case this can cause the Java Server to restart since it remains unresponsive during garbage collection and certain timeouts may expire.
CPU overloaded:
Since GC is a CPU-bound operation (requires a lot of CPU), CPU shortage could lead to high CPU duration.
Not optimal VM memory configuration:
Sometimes the VM is started with huge start memory and there is a lot of work for the GC when the VM triggers it for the first time. Clearing gigabytes of unused objects usually takes long time.
Solution:
Step 1:
Check if the operating system is paging – if there is a lot of paging this is an issue.
Step 2:
Check if there is enough physical PC memory – if there is not enough this is an issue – try to free some OS memory or increase the PC physical memory.
Step 3:
Check if there are other processes that are consuming CPU power – if there are such consumers – stop them if possible.
Step 4:
Usually the -Xms and -Xmx are equal – a good approach is to reduce the -Xms so the VM is running the full GCs more often for short times, thus memory defragmentation is decreased.
Step5:
Need to keep updated SAP JVM version with our SAP NetWeaver Release, sometime updating SAP JVM version solve this issue. So you can refer latest SAP Note to check JVM for your NW release.
Note: If issue still persist the open a ticket with SAP support with adequate logs to check more.