Database Reference
In-Depth Information
you are randomly getting OutofMemory errors, it is most likely your al-
located memory is not sufficient for the thread count configured for the
application server(s). Go back to testing lab and run the load scenari-
os to identify memory and thread count settings. One must identify the
root cause for memory leaks as this is usually due to the bad applica-
tion design, third party library bugs, and/or implementation. It is a leading
practice, to restart application server(s) periodically until a permanent fix
is identified for the memory leak issues.
The performance of the garbage collector is very important for an application's per-
formance. An application that spends 10 percent of its time in garbage collection can
lose 75 percent of its throughput when scaled out to 32 processors.
As shown in the following screenshot, one of the common errors from JVM is
OutOfMemoryError
exception:
Adjusting JVM memory parameters will resolve most of the memory issues including
OutOfMemoryError exceptions. Increasing the minimum and maximum heap size
along with the perm size is one of the solutions for resolving OutOfMemoryError ex-
ceptions. It is recommended that you use 80 percent of available host memory as
JVM maximum memory and save the remaining for the operating system and other
processes. If you are running multiple JVM(s) to run an admin server and multiple
managed servers then it is recommended to create a dedicated memory share for
each JVM from the 80 percent of the available host memory.
One can use a large heap size provided that it is not causing the system to "swap"
pages to the disk. But it is recommended to not keep the value very high; setting up
a very high heap size might lead to wasted memory and that makes full garbage col-
lection slower and garbage collection occurs less frequently. The objective here is to
utilize the largest JVM size that has the smallest window for full garbage collection
for an application on a system.
