GC (Allocation Failure) [PSYoungGen]
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.
java garbage-collection
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
|
show 5 more comments
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.
java garbage-collection
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
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 Goate
Nov 13 '18 at 9: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 Goate
Nov 13 '18 at 9: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 9:17
But prior moving to java8, there was no such Allocation Failure in gc logs.
– Bhaskar
Nov 13 '18 at 9:18
What I am questioning is that even if you set the new to 5Gb, I think (docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…) withSurvivorRatiodefault being8I 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 Goate
Nov 13 '18 at 9:22
|
show 5 more comments
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.
java garbage-collection
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
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.
java garbage-collection
java garbage-collection
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
edited Nov 13 '18 at 8:06
Bhaskar
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
asked Nov 13 '18 at 7:49
BhaskarBhaskar
4710
4710
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 Goate
Nov 13 '18 at 9: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 Goate
Nov 13 '18 at 9: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 9:17
But prior moving to java8, there was no such Allocation Failure in gc logs.
– Bhaskar
Nov 13 '18 at 9:18
What I am questioning is that even if you set the new to 5Gb, I think (docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…) withSurvivorRatiodefault being8I 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 Goate
Nov 13 '18 at 9:22
|
show 5 more comments
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 Goate
Nov 13 '18 at 9: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 Goate
Nov 13 '18 at 9: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 9:17
But prior moving to java8, there was no such Allocation Failure in gc logs.
– Bhaskar
Nov 13 '18 at 9:18
What I am questioning is that even if you set the new to 5Gb, I think (docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…) withSurvivorRatiodefault being8I 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 Goate
Nov 13 '18 at 9:22
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 Goate
Nov 13 '18 at 9:12
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 Goate
Nov 13 '18 at 9: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 Goate
Nov 13 '18 at 9:16
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 Goate
Nov 13 '18 at 9: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 9:17
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 9:17
But prior moving to java8, there was no such Allocation Failure in gc logs.
– Bhaskar
Nov 13 '18 at 9:18
But prior moving to java8, there was no such Allocation Failure in gc logs.
– Bhaskar
Nov 13 '18 at 9:18
What I am questioning is that even if you set the new to 5Gb, I think (docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…) 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 Goate
Nov 13 '18 at 9:22
What I am questioning is that even if you set the new to 5Gb, I think (docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…) 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 Goate
Nov 13 '18 at 9:22
|
show 5 more comments
1 Answer
1
active
oldest
votes
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.
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53276185%2fgc-allocation-failure-psyounggen%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
add a comment |
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.
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
add a comment |
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.
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
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.
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
answered Nov 13 '18 at 10:03
David GoateDavid Goate
1,12721536
1,12721536
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53276185%2fgc-allocation-failure-psyounggen%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 Goate
Nov 13 '18 at 9: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 Goate
Nov 13 '18 at 9: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 9:17
But prior moving to java8, there was no such Allocation Failure in gc logs.
– Bhaskar
Nov 13 '18 at 9:18
What I am questioning is that even if you set the new to 5Gb, I think (docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…) with
SurvivorRatiodefault being8I 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 Goate
Nov 13 '18 at 9:22