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
GC activity and duration can be seen in the SAP Management Console:
The Garbage Collector is running for a long time.
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 pagefault is a time consuming operation, the number of pagefaults is crucial for GC perforamce.
- 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.
Check if the operating system is paging - if there is a lot of paging this is an issue.
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.
Check if there are other processes that are consuming CPU power - if there are such consumers - stop them if possible.
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.