CODEWITHSUNDEEP
javaperformancegarbage-collection
Guru
Guru

Reputation: 1

What is a good gc tuning strategy for gc output that I have?

This is the output after running for around 10 minutes. 

Heap
 PSYoungGen      total 7040K, used 0K [0x24060000, 0x247c0000, 0x26790000)
  eden space 6528K, 0% used [0x24060000,0x24060000,0x246c0000)
  from space 512K, 0% used [0x246c0000,0x246c0000,0x24740000)
  to   space 512K, 0% used [0x24740000,0x24740000,0x247c0000)
 ParOldGen       total 48896K, used 43303K [0x06990000, 0x09950000, 0x24060000)
  object space 48896K, 88% used [0x06990000,0x093d9d80,0x09950000)
 PSPermGen       total 12288K, used 3737K [0x02990000, 0x03590000, 0x06990000)
  object space 12288K, 30% used [0x02990000,0x02d366c0,0x03590000)
[GC [PSYoungGen: 0K->0K(7040K)] 43303K->43303K(55936K), 0.0005129 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System) [PSYoungGen: 0K->0K(7040K)] [ParOldGen: 43303K->43303K(48896K)] 43303K->43303K(55936K) [PSPermGen: 3737K->3737K(12288K)], 0.1964557 secs] [Times: user=0.36 sys=0.00, real=0.19 secs]

Thanks in advance

Upvotes: 0

Views: 452

Answers (3)

user492238
user492238

Reputation: 4084

Might have to do with too many large objects being created (and not released) from your application? Dont know the Java GC really, but coming from .NET, large objects are placed on a seperate large object heap which is not compacted by the GC. In an application, utilizing a busy allocation pattern, this could lead to fragmentation on the LOB -> which in turn often causes those nasty OutOfMemory (OOM) exceptions. Moreover, LOB collections are always generation 2 collections. This means, they are costly! So, the clean solution would be to implement a pooling. Implement a disposal pattern for your large objects and make sure, they are released to the pool after use. Reuse them for new objects by reclaiming them from the pool. Once again, this does only apply, if you have too many large allocations. So you may clear this out first.

Upvotes: 0

user207421
user207421

Reputation: 310907

If you're running out of memory the problem is not GC, the problem is that you are using too many objects and not releasing them.

The last time I worried about Java's GC was in 1998.

Upvotes: 1

phisch
phisch

Reputation: 4731

I'd recommend using something like JConsole (JDK 1.5+) or jVisualVM (JDK1.6). A single output of printgc is not enough to give a good recommendation.

There are usually two issues: You create too many new Objects, the New Generations fills up quickly and thus the gc moves all those objects to the Survivor Space or even Perm Generation. If this is what happens (they get deleted with the next full gc, which takes longer), I'd recommend to increase the Young/New generation. (-XX:NewSize). This allows the Objects to get unreferenced and deleted by a regular gc.

If you do have many long lived objects, I'd check if that is really necessary. This might mean you have to change code.

Keep in mind, that a large heap takes longer to gc compared to a small heap.

Upvotes: 2

Related Questions