Spring boot, JVM too many or just enough parameters?











up vote
1
down vote

favorite
2












I'm trying to tune production JVMs for spring boot Microservices and for now I made this list



-XX:+UnlockExperimentalVMOptions 
-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction=2
-XX:+UseStringDeduplication
-XX:+PrintStringDeduplicationStatistics
-XX:+CrashOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseG1GC
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/tmp/gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=2000k
-XX:HeapDumpPath='/var/log/heap_dump.log'
-XX:+UseGCOverheadLimit
-XX:NativeMemoryTracking=summary
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintNMTStatistics


What do you think, if I noticed that non of them 'duplicate' their functionality but I'm still not 100% is it enough or maybe I could add/remove some of them without worry of losing information.



my aim is to get as many information what is happening in jvm as I can get and to tune memory/gc performance to avoid oom.
App is running on was in docker.



Some details: jdk 1.8 u152
spring-boot(s): 1.5.1










share|improve this question
























  • but now looking closely the majority of them is just to print something on failure or not, so they don't really "tune" anything. besides this one UseCGroupMemoryLimitForHeap - unless you use a container, this is useless and this one MaxRAMFraction.
    – Eugene
    Nov 14 at 9:32










  • the first two comments are off - I admit, removed them; my bad. the next one is not off, i just wanted to mention that before adding any GC parameters, like UseCGroupMemoryLimitForHeap - which only applies when you use a container. Do you understand what this one even does? It seems like you are trying to get a "magical" set of arguments for your JVM, without ever knowing what is going on inside your application - this is close to impossible. I will not comment any further.
    – Eugene
    Nov 14 at 11:03






  • 2




    For what target do you want to "tune"? It seems like your jvm will be busy printing tons of info instead of processing actual requests.
    – SpaceTrucker
    Nov 14 at 11:54










  • yea, cause I need to monitor all unwanted behaviour that potentially happens and have kind of log of this action. So if app start struggling with some task and then just disappear from dashboard I want to have all possible ways to check what is going on. Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics. So goal is to have memory optimized fully logged jvm.
    – shutdown -h now
    Nov 14 at 12:37










  • Depending on your JVM, many of these look like the default options, but most of these are unlikely to cause a problem.
    – Peter Lawrey
    Nov 15 at 8:52















up vote
1
down vote

favorite
2












I'm trying to tune production JVMs for spring boot Microservices and for now I made this list



-XX:+UnlockExperimentalVMOptions 
-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction=2
-XX:+UseStringDeduplication
-XX:+PrintStringDeduplicationStatistics
-XX:+CrashOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseG1GC
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/tmp/gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=2000k
-XX:HeapDumpPath='/var/log/heap_dump.log'
-XX:+UseGCOverheadLimit
-XX:NativeMemoryTracking=summary
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintNMTStatistics


What do you think, if I noticed that non of them 'duplicate' their functionality but I'm still not 100% is it enough or maybe I could add/remove some of them without worry of losing information.



my aim is to get as many information what is happening in jvm as I can get and to tune memory/gc performance to avoid oom.
App is running on was in docker.



Some details: jdk 1.8 u152
spring-boot(s): 1.5.1










share|improve this question
























  • but now looking closely the majority of them is just to print something on failure or not, so they don't really "tune" anything. besides this one UseCGroupMemoryLimitForHeap - unless you use a container, this is useless and this one MaxRAMFraction.
    – Eugene
    Nov 14 at 9:32










  • the first two comments are off - I admit, removed them; my bad. the next one is not off, i just wanted to mention that before adding any GC parameters, like UseCGroupMemoryLimitForHeap - which only applies when you use a container. Do you understand what this one even does? It seems like you are trying to get a "magical" set of arguments for your JVM, without ever knowing what is going on inside your application - this is close to impossible. I will not comment any further.
    – Eugene
    Nov 14 at 11:03






  • 2




    For what target do you want to "tune"? It seems like your jvm will be busy printing tons of info instead of processing actual requests.
    – SpaceTrucker
    Nov 14 at 11:54










  • yea, cause I need to monitor all unwanted behaviour that potentially happens and have kind of log of this action. So if app start struggling with some task and then just disappear from dashboard I want to have all possible ways to check what is going on. Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics. So goal is to have memory optimized fully logged jvm.
    – shutdown -h now
    Nov 14 at 12:37










  • Depending on your JVM, many of these look like the default options, but most of these are unlikely to cause a problem.
    – Peter Lawrey
    Nov 15 at 8:52













up vote
1
down vote

favorite
2









up vote
1
down vote

favorite
2






2





I'm trying to tune production JVMs for spring boot Microservices and for now I made this list



-XX:+UnlockExperimentalVMOptions 
-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction=2
-XX:+UseStringDeduplication
-XX:+PrintStringDeduplicationStatistics
-XX:+CrashOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseG1GC
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/tmp/gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=2000k
-XX:HeapDumpPath='/var/log/heap_dump.log'
-XX:+UseGCOverheadLimit
-XX:NativeMemoryTracking=summary
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintNMTStatistics


What do you think, if I noticed that non of them 'duplicate' their functionality but I'm still not 100% is it enough or maybe I could add/remove some of them without worry of losing information.



my aim is to get as many information what is happening in jvm as I can get and to tune memory/gc performance to avoid oom.
App is running on was in docker.



Some details: jdk 1.8 u152
spring-boot(s): 1.5.1










share|improve this question















I'm trying to tune production JVMs for spring boot Microservices and for now I made this list



-XX:+UnlockExperimentalVMOptions 
-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction=2
-XX:+UseStringDeduplication
-XX:+PrintStringDeduplicationStatistics
-XX:+CrashOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseG1GC
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/tmp/gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=2000k
-XX:HeapDumpPath='/var/log/heap_dump.log'
-XX:+UseGCOverheadLimit
-XX:NativeMemoryTracking=summary
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintNMTStatistics


What do you think, if I noticed that non of them 'duplicate' their functionality but I'm still not 100% is it enough or maybe I could add/remove some of them without worry of losing information.



my aim is to get as many information what is happening in jvm as I can get and to tune memory/gc performance to avoid oom.
App is running on was in docker.



Some details: jdk 1.8 u152
spring-boot(s): 1.5.1







java spring-boot java-8 jvm jvm-arguments






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 23 at 10:24

























asked Nov 14 at 9:03









shutdown -h now

368516




368516












  • but now looking closely the majority of them is just to print something on failure or not, so they don't really "tune" anything. besides this one UseCGroupMemoryLimitForHeap - unless you use a container, this is useless and this one MaxRAMFraction.
    – Eugene
    Nov 14 at 9:32










  • the first two comments are off - I admit, removed them; my bad. the next one is not off, i just wanted to mention that before adding any GC parameters, like UseCGroupMemoryLimitForHeap - which only applies when you use a container. Do you understand what this one even does? It seems like you are trying to get a "magical" set of arguments for your JVM, without ever knowing what is going on inside your application - this is close to impossible. I will not comment any further.
    – Eugene
    Nov 14 at 11:03






  • 2




    For what target do you want to "tune"? It seems like your jvm will be busy printing tons of info instead of processing actual requests.
    – SpaceTrucker
    Nov 14 at 11:54










  • yea, cause I need to monitor all unwanted behaviour that potentially happens and have kind of log of this action. So if app start struggling with some task and then just disappear from dashboard I want to have all possible ways to check what is going on. Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics. So goal is to have memory optimized fully logged jvm.
    – shutdown -h now
    Nov 14 at 12:37










  • Depending on your JVM, many of these look like the default options, but most of these are unlikely to cause a problem.
    – Peter Lawrey
    Nov 15 at 8:52


















  • but now looking closely the majority of them is just to print something on failure or not, so they don't really "tune" anything. besides this one UseCGroupMemoryLimitForHeap - unless you use a container, this is useless and this one MaxRAMFraction.
    – Eugene
    Nov 14 at 9:32










  • the first two comments are off - I admit, removed them; my bad. the next one is not off, i just wanted to mention that before adding any GC parameters, like UseCGroupMemoryLimitForHeap - which only applies when you use a container. Do you understand what this one even does? It seems like you are trying to get a "magical" set of arguments for your JVM, without ever knowing what is going on inside your application - this is close to impossible. I will not comment any further.
    – Eugene
    Nov 14 at 11:03






  • 2




    For what target do you want to "tune"? It seems like your jvm will be busy printing tons of info instead of processing actual requests.
    – SpaceTrucker
    Nov 14 at 11:54










  • yea, cause I need to monitor all unwanted behaviour that potentially happens and have kind of log of this action. So if app start struggling with some task and then just disappear from dashboard I want to have all possible ways to check what is going on. Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics. So goal is to have memory optimized fully logged jvm.
    – shutdown -h now
    Nov 14 at 12:37










  • Depending on your JVM, many of these look like the default options, but most of these are unlikely to cause a problem.
    – Peter Lawrey
    Nov 15 at 8:52
















but now looking closely the majority of them is just to print something on failure or not, so they don't really "tune" anything. besides this one UseCGroupMemoryLimitForHeap - unless you use a container, this is useless and this one MaxRAMFraction.
– Eugene
Nov 14 at 9:32




but now looking closely the majority of them is just to print something on failure or not, so they don't really "tune" anything. besides this one UseCGroupMemoryLimitForHeap - unless you use a container, this is useless and this one MaxRAMFraction.
– Eugene
Nov 14 at 9:32












the first two comments are off - I admit, removed them; my bad. the next one is not off, i just wanted to mention that before adding any GC parameters, like UseCGroupMemoryLimitForHeap - which only applies when you use a container. Do you understand what this one even does? It seems like you are trying to get a "magical" set of arguments for your JVM, without ever knowing what is going on inside your application - this is close to impossible. I will not comment any further.
– Eugene
Nov 14 at 11:03




the first two comments are off - I admit, removed them; my bad. the next one is not off, i just wanted to mention that before adding any GC parameters, like UseCGroupMemoryLimitForHeap - which only applies when you use a container. Do you understand what this one even does? It seems like you are trying to get a "magical" set of arguments for your JVM, without ever knowing what is going on inside your application - this is close to impossible. I will not comment any further.
– Eugene
Nov 14 at 11:03




2




2




For what target do you want to "tune"? It seems like your jvm will be busy printing tons of info instead of processing actual requests.
– SpaceTrucker
Nov 14 at 11:54




For what target do you want to "tune"? It seems like your jvm will be busy printing tons of info instead of processing actual requests.
– SpaceTrucker
Nov 14 at 11:54












yea, cause I need to monitor all unwanted behaviour that potentially happens and have kind of log of this action. So if app start struggling with some task and then just disappear from dashboard I want to have all possible ways to check what is going on. Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics. So goal is to have memory optimized fully logged jvm.
– shutdown -h now
Nov 14 at 12:37




yea, cause I need to monitor all unwanted behaviour that potentially happens and have kind of log of this action. So if app start struggling with some task and then just disappear from dashboard I want to have all possible ways to check what is going on. Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics. So goal is to have memory optimized fully logged jvm.
– shutdown -h now
Nov 14 at 12:37












Depending on your JVM, many of these look like the default options, but most of these are unlikely to cause a problem.
– Peter Lawrey
Nov 15 at 8:52




Depending on your JVM, many of these look like the default options, but most of these are unlikely to cause a problem.
– Peter Lawrey
Nov 15 at 8:52












1 Answer
1






active

oldest

votes

















up vote
1
down vote














Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics




A process shouldn't just die, it should have either an exception or a crash dump. If your machine is overloaded, your process might get killed on linux to protect the system. If this happens it should be logged in /var/log/messages



See https://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short



If your program is randomly calling System.exit(int) your SecurityManager should be preventing it or at least logging it.




So goal is to have memory optimized fully logged jvm.




Unfortunately, many of the logs you mention are buffered, so if the process is killed you are likely to lose the last few entries, possible the last few minutes of logging. These logs are useful for diagnosing performance issues, but might not help determine why the process dies unexpectedly.




tune memory/gc performance to avoid oom




This is different sort of problem. You need to try




  • giving the process a lot more memory and see at what point the process doesn't die.

  • if this works, your process needs more memory, if your process continues to consume memory over time you might have a memory leak.

  • if you keep getting OutOfMemoryErrors in the similar places in the code, this is most likely the place where it is consuming too much memory.

  • most likely, you don't have enough memory for the tasks it is performing. I would then look at the memory profile using a profiler, such as flight recorder, to see if you can reduce how much is used. At some point you either solve the problem by reducing usage, or have to give the process more memory.


Given memory is cheap, and your time is not, it might be simpler to increase memory. i.e. keep in mind how much memory can you buy for a day of your time.






share|improve this answer























  • ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
    – shutdown -h now
    Nov 15 at 10:16











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',
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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53296389%2fspring-boot-jvm-too-many-or-just-enough-parameters%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








up vote
1
down vote














Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics




A process shouldn't just die, it should have either an exception or a crash dump. If your machine is overloaded, your process might get killed on linux to protect the system. If this happens it should be logged in /var/log/messages



See https://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short



If your program is randomly calling System.exit(int) your SecurityManager should be preventing it or at least logging it.




So goal is to have memory optimized fully logged jvm.




Unfortunately, many of the logs you mention are buffered, so if the process is killed you are likely to lose the last few entries, possible the last few minutes of logging. These logs are useful for diagnosing performance issues, but might not help determine why the process dies unexpectedly.




tune memory/gc performance to avoid oom




This is different sort of problem. You need to try




  • giving the process a lot more memory and see at what point the process doesn't die.

  • if this works, your process needs more memory, if your process continues to consume memory over time you might have a memory leak.

  • if you keep getting OutOfMemoryErrors in the similar places in the code, this is most likely the place where it is consuming too much memory.

  • most likely, you don't have enough memory for the tasks it is performing. I would then look at the memory profile using a profiler, such as flight recorder, to see if you can reduce how much is used. At some point you either solve the problem by reducing usage, or have to give the process more memory.


Given memory is cheap, and your time is not, it might be simpler to increase memory. i.e. keep in mind how much memory can you buy for a day of your time.






share|improve this answer























  • ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
    – shutdown -h now
    Nov 15 at 10:16















up vote
1
down vote














Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics




A process shouldn't just die, it should have either an exception or a crash dump. If your machine is overloaded, your process might get killed on linux to protect the system. If this happens it should be logged in /var/log/messages



See https://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short



If your program is randomly calling System.exit(int) your SecurityManager should be preventing it or at least logging it.




So goal is to have memory optimized fully logged jvm.




Unfortunately, many of the logs you mention are buffered, so if the process is killed you are likely to lose the last few entries, possible the last few minutes of logging. These logs are useful for diagnosing performance issues, but might not help determine why the process dies unexpectedly.




tune memory/gc performance to avoid oom




This is different sort of problem. You need to try




  • giving the process a lot more memory and see at what point the process doesn't die.

  • if this works, your process needs more memory, if your process continues to consume memory over time you might have a memory leak.

  • if you keep getting OutOfMemoryErrors in the similar places in the code, this is most likely the place where it is consuming too much memory.

  • most likely, you don't have enough memory for the tasks it is performing. I would then look at the memory profile using a profiler, such as flight recorder, to see if you can reduce how much is used. At some point you either solve the problem by reducing usage, or have to give the process more memory.


Given memory is cheap, and your time is not, it might be simpler to increase memory. i.e. keep in mind how much memory can you buy for a day of your time.






share|improve this answer























  • ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
    – shutdown -h now
    Nov 15 at 10:16













up vote
1
down vote










up vote
1
down vote










Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics




A process shouldn't just die, it should have either an exception or a crash dump. If your machine is overloaded, your process might get killed on linux to protect the system. If this happens it should be logged in /var/log/messages



See https://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short



If your program is randomly calling System.exit(int) your SecurityManager should be preventing it or at least logging it.




So goal is to have memory optimized fully logged jvm.




Unfortunately, many of the logs you mention are buffered, so if the process is killed you are likely to lose the last few entries, possible the last few minutes of logging. These logs are useful for diagnosing performance issues, but might not help determine why the process dies unexpectedly.




tune memory/gc performance to avoid oom




This is different sort of problem. You need to try




  • giving the process a lot more memory and see at what point the process doesn't die.

  • if this works, your process needs more memory, if your process continues to consume memory over time you might have a memory leak.

  • if you keep getting OutOfMemoryErrors in the similar places in the code, this is most likely the place where it is consuming too much memory.

  • most likely, you don't have enough memory for the tasks it is performing. I would then look at the memory profile using a profiler, such as flight recorder, to see if you can reduce how much is used. At some point you either solve the problem by reducing usage, or have to give the process more memory.


Given memory is cheap, and your time is not, it might be simpler to increase memory. i.e. keep in mind how much memory can you buy for a day of your time.






share|improve this answer















Currently i'am dealing with situations that app is just working few seconds or even minutes and immediately die without simple log and event error in Dropwizard Metrics




A process shouldn't just die, it should have either an exception or a crash dump. If your machine is overloaded, your process might get killed on linux to protect the system. If this happens it should be logged in /var/log/messages



See https://unix.stackexchange.com/questions/136291/will-linux-start-killing-my-processes-without-asking-me-if-memory-gets-short



If your program is randomly calling System.exit(int) your SecurityManager should be preventing it or at least logging it.




So goal is to have memory optimized fully logged jvm.




Unfortunately, many of the logs you mention are buffered, so if the process is killed you are likely to lose the last few entries, possible the last few minutes of logging. These logs are useful for diagnosing performance issues, but might not help determine why the process dies unexpectedly.




tune memory/gc performance to avoid oom




This is different sort of problem. You need to try




  • giving the process a lot more memory and see at what point the process doesn't die.

  • if this works, your process needs more memory, if your process continues to consume memory over time you might have a memory leak.

  • if you keep getting OutOfMemoryErrors in the similar places in the code, this is most likely the place where it is consuming too much memory.

  • most likely, you don't have enough memory for the tasks it is performing. I would then look at the memory profile using a profiler, such as flight recorder, to see if you can reduce how much is used. At some point you either solve the problem by reducing usage, or have to give the process more memory.


Given memory is cheap, and your time is not, it might be simpler to increase memory. i.e. keep in mind how much memory can you buy for a day of your time.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 15 at 9:07

























answered Nov 15 at 8:57









Peter Lawrey

439k55556958




439k55556958












  • ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
    – shutdown -h now
    Nov 15 at 10:16


















  • ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
    – shutdown -h now
    Nov 15 at 10:16
















ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
– shutdown -h now
Nov 15 at 10:16




ou, that's interesting, but at all giving memory is maybe cheap if we are talking about local environment rather then make kind of experiment on AWS environment where then I should somehow document if my 'changes' give any 'real - business result ' so maybe I will just introduce major parameters and then I will extends. I think the most important are '-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='/var/log/heap_dump.log'. Thanks for help, for sure I will investigate that potential System.exit(int), it's new for me.
– shutdown -h now
Nov 15 at 10:16


















draft saved

draft discarded




















































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.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53296389%2fspring-boot-jvm-too-many-or-just-enough-parameters%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?