Spring boot, JVM too many or just enough parameters?
up vote
1
down vote
favorite
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
add a comment |
up vote
1
down vote
favorite
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
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 oneUseCGroupMemoryLimitForHeap
- unless you use a container, this is useless and this oneMaxRAMFraction
.
– 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, likeUseCGroupMemoryLimitForHeap
- 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
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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
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
java spring-boot java-8 jvm jvm-arguments
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 oneUseCGroupMemoryLimitForHeap
- unless you use a container, this is useless and this oneMaxRAMFraction
.
– 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, likeUseCGroupMemoryLimitForHeap
- 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
add a comment |
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 oneUseCGroupMemoryLimitForHeap
- unless you use a container, this is useless and this oneMaxRAMFraction
.
– 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, likeUseCGroupMemoryLimitForHeap
- 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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
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.
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.
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%2f53296389%2fspring-boot-jvm-too-many-or-just-enough-parameters%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
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 oneMaxRAMFraction
.– 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