Use JVM default stacksize #9135
Assignees
Labels
Comments
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this issue
Jan 6, 2015
We used to reduces the stack size to 256kb. This commit removes this optimization and relies on the JVMs default. Closes elastic#9135
s1monw
added a commit
that referenced
this issue
Jan 6, 2015
We used to reduces the stack size to 256kb. This commit removes this optimization and relies on the JVMs default. Closes #9135
jpountz
added a commit
to jpountz/elasticsearch
that referenced
this issue
Apr 2, 2015
Follow-up of elastic#9135. We initially decreased the stack size because it would end up a lot of memory when there are many threads. But we also have some thread pools that may be oversized, in particular the search thread pool. This commit proposes to decrease the default search thread pool size from `3 * num_procs` to `3 * num_procs / 2 + 1`. This is large enough to be sure that we can use all the machine resources even with a search-only work load but not too large in order to not consume too much memory because of the stack size and thread locals.
jpountz
added a commit
that referenced
this issue
Apr 7, 2015
Follow-up of #9135. We initially decreased the stack size because it would end up a lot of memory when there are many threads. But we also have some thread pools that may be oversized, in particular the search thread pool. This commit proposes to decrease the default search thread pool size from `3 * num_procs` to `3 * num_procs / 2 + 1`. This is large enough to be sure that we can use all the machine resources even with a search-only work load but not too large in order to not consume too much memory because of the stack size and thread locals.
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
related to elastic/elasticsearch#9135 also sync JAVA_OPTS with current ES opts
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
related to elastic/elasticsearch#9135 also sync JAVA_OPTS with current ES opts
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
related to elastic/elasticsearch#9135 also sync JAVA_OPTS with current ES opts
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
related to elastic/elasticsearch#9135 also sync JAVA_OPTS with current ES opts
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
related to elastic/elasticsearch#9135 also sync JAVA_OPTS with current ES opts
seut
added a commit
to crate/crate
that referenced
this issue
Nov 4, 2016
related to elastic/elasticsearch#9135 also sync JAVA_OPTS with current ES opts
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We reduce the stack size dramatically to 256kb vs. 64bit JVM defaults of 1024kb. This can cause issues like #9127
The reduces stack size was added years ago to prevent large heap usage due to too many thread. The story around threads is much better these days in Elasticsearch although not perfect. Nevertheless, the default seems to be lowish and we should rather default to the JVM defaults. This might also allow us to take advantage of not yet fully utilized features like stack allocations in future JVM version.
The text was updated successfully, but these errors were encountered: