3

Recently we switched our code to java8 from java7. We are getting GC allocation failure in every 10 minuts for PSYoungGen. We even tried having switch -XX:NewSize and -XX:NewMaxSize in place to around 5GB(total heap size is 10GB). But even after gc allocation failure is getting printed and PSYoungGen is triggering to the almost the size(5GB). Added some logs :

[GC (Allocation Failure) [PSYoungGen: 3145728K->114922K(3670016K)] 3145728K->115026K(5767168K), 0.2511084 secs] [Times: user=0.26 sys=0.14, real=0.25 secs]
[GC (Allocation Failure) [PSYoungGen: 4443141K->125893K(4718592K)] 4443261K->126229K(6815744K), 0.2318927 secs] [Times: user=0.42 sys=0.22, real=0.24 secs]

In one of answers: Java GC (Allocation Failure) related to this I have seen this is normal behavior, just curious to know is there any way to overcome this ? Thanks.

Hearen
  • 7,420
  • 4
  • 53
  • 63
Bhaskar
  • 159
  • 1
  • 2
  • 17
  • Is it possible that this was happening before and you are now just seeing that it's happening due to some increased logging that might have been introduced in jre8? Do you know what kind of allocations you routinely make (e.g. are they very large in size)? – David Nov 13 '18 at 09:12
  • I think it is the case that the NewSize you might be setting is controlling the size of the entire new generation (which is composed of eden and survivor spaces) so perhaps your eden is still not sufficiently sized to allocate directly into for new large objects (perhaps large byte[]'s for example) – David Nov 13 '18 at 09:16
  • Major GC consumption is in young generation only and not in old. We have 10 GB allocated in totalfor heap and out of which 5GB for young. – Bhaskar Nov 13 '18 at 09:17
  • But prior moving to java8, there was no such Allocation Failure in gc logs. – Bhaskar Nov 13 '18 at 09:18
  • What I am questioning is that even if you set the new to 5Gb, I think (https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/sizing.html) with `SurvivorRatio` default being `8` I think would mean approx 1.25Gb of survivor space, leaving 3.75 Gb eden. Is it possible you allocate objects close to this size? – David Nov 13 '18 at 09:22
  • 1
    With regards to the no such logs, in the answer you link to in your OP the accepted answer makes the comment "Older JVM were not printing GC cause for minor GC cycles.". So perhaps this was always happening and you just didn't know until now. – David Nov 13 '18 at 09:23
  • Thanks David, I think these logs will be there as part of new jvm. For allocation of objects I will check. Thanks for your comments. – Bhaskar Nov 13 '18 at 09:55
  • No problem I'll move to answers, would appreciate (if it's helped) for you to mark as accepted. – David Nov 13 '18 at 10:01
  • You want “to overcome” a normal behavior? That doesn’t make any sense. – Holger Nov 13 '18 at 10:19
  • I have to say the a scavenge every 10 mins shouldn't be regarded as a lot or a problem in any way, depending on application. I don't know what your app does but if it allocates any memory at all that is not bad. The scavenges are quite long, if that is problem or not depends on what your app is doing. – Erik Nov 14 '18 at 16:36

1 Answers1

3

I think it is the case that the NewSize you might be setting is controlling the size of the entire new generation (which is composed of eden and survivor spaces) so perhaps your eden is still not sufficiently sized to allocate directly into for new large objects (perhaps large byte[]'s for example).

What I am questioning is that even if you set the new to 5Gb, I think Oracle's docs suggest with SurvivorRatio default being 8 would mean approx 1.25Gb of survivor space, leaving 3.75 Gb eden. Is it possible you allocate objects above or close to this size?

With regards to the no such logs, in the answer you link to in your OP the accepted answer makes the comment

"Older JVM were not printing GC cause for minor GC cycles.

So perhaps this was always happening and you just didn't know until now.

David
  • 7,652
  • 21
  • 60
  • 98