Skip to main content

Garbage collector frequent fullGC on 60G allocated RAM

3 replies [Last post]
korff
Offline
Joined: 2009-06-10
Points: 0

Hi,

The java garbage collector of our application starts a fullGC evry 60 secs. The fullGC takes allmost 60 secs. so there is few time left for thread excecution. The frequent fullGC call is only observed when files with serialized objects were red in. Additionally some new threads (7) have to be started which refer to the objects.

RAM 64GB
Processors: Two processor system with 8 cores
OS: Linux
Java 1.5

commandline:
java -verbosegc -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+DisableExplicitGC -XX:MaxNewSize=20g -XX:NewSize=20g -XX:+UseParallelGC -Xms60g -Xmx60g -classpath $A_CLASSPATH com.xyz.research.chem.vs.business.rmi.ServerVS $*

The size of the heap is quite big with 60G but the memory is needed for 20 Mio. records. The program starts with reading approx. 20 Mio. records from files into the memory with every record an instance of a class. The loading can be done in two ways: The records are taken from our own file format. The other possibility is to read serialized objects from file.
Independendly whether the records were taken from our file format or from the serialized object files everything is working fine. No frequent fullGC is observed. The problems occur later on.
An RMI service is waiting for input after the read in. When the RMI service is called seven threads are generated and started to compare a few records, given via the RMI interface, with the 20 Mio records in the heap. And here it becomes strange, if the read in of the objects was done from our in-house format the comparison runs on the seven threads without any problems. But when the read in was done from the serialized objects the garbage collector is called with a fullGC every minute which results in null performance for the record comparisons.

With jmap -heap I received the following:
For the in-house data format

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 64424509440 (61440.0MB)
NewSize = 21474836480 (20480.0MB)
MaxNewSize = 21474836480 (20480.0MB)
OldSize = 1835008 (1.75MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 88080384 (84.0MB)

Heap Usage:
PS Young Generation
Eden Space:
capacity = 21472608256 (20477.875MB)
used = 4050172072 (3862.545082092285MB)
free = 17422436184 (16615.329917907715MB)
18.862040529558293% used
From Space:
capacity = 1114112 (1.0625MB)
used = 524288 (0.5MB)
free = 589824 (0.5625MB)
47.05882352941177% used
To Space:
capacity = 1114112 (1.0625MB)
used = 0 (0.0MB)
free = 1114112 (1.0625MB)
0.0% used
PS Old Generation
capacity = 42949672960 (40960.0MB)
used = 37418332168 (35684.902351379395MB)
free = 5531340792 (5275.0976486206055MB)
87.12134363129735% used
PS Perm Generation
capacity = 21757952 (20.75MB)
used = 12451000 (11.874198913574219MB)
free = 9306952 (8.875801086425781MB)
57.225055005176955% used

For reading the serialized objects and starting the comparison

Attaching to process ID 19156, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.5.0_17-b04

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 64424509440 (61440.0MB)
NewSize = 21474836480 (20480.0MB)
MaxNewSize = -65536 (-0.0625MB)
OldSize = 1835008 (1.75MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 88080384 (84.0MB)

Heap Usage:
PS Young Generation
Eden Space:
capacity = 16106127360 (15360.0MB)
used = 16106127360 (15360.0MB)
free = 0 (0.0MB)
100.0% used
From Space:
capacity = 2684354560 (2560.0MB)
used = 0 (0.0MB)
free = 2684354560 (2560.0MB)
0.0% used
To Space:
capacity = 2684354560 (2560.0MB)
used = 0 (0.0MB)
free = 2684354560 (2560.0MB)
0.0% used
PS Old Generation
capacity = 42949672960 (40960.0MB)
used = 34966749296 (33346.89073181152MB)
free = 7982923664 (7613.109268188477MB)
81.41330745071173% used
PS Perm Generation
capacity = 21757952 (20.75MB)
used = 10592616 (10.101905822753906MB)
free = 11165336 (10.648094177246094MB)
48.683883483151355% used

Any help is really appreciated,
because the read in from the serialized objects is ten times faster than from our in-house format.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
linuxhippy
Offline
Joined: 2004-01-07
Points: 0

RMI executes a GC cycles every 60 seconds by default, to be able to track dead objects.

You can change that intervall with:
-Dsun.rmi.dgc.server.gcInterval=600000
-Dsun.rmi.dgc.client.gcInterval=600000

- Clemens

korff
Offline
Joined: 2009-06-10
Points: 0

The call by the RMI server is allready suppressed by the commandline option -XX:+DisableExplicitGC.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

Ok.

Well, some gc logs would be nescessary to see whats going on...

- Clemens