Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bound processor size based cals to 32 #3545

Closed
kimchy opened this Issue Aug 20, 2013 · 0 comments

Comments

Projects
None yet
1 participant
@kimchy
Copy link
Member

kimchy commented Aug 20, 2013

We use number of processors to choose default thread pool sizes, and number of workers in networking (for HTTP and transport). Bound it to max at 32 by default as a safety measure to create too many threads.

This relates to #3478, where we set the default to 24, but 32 is probably a better default.

@kimchy kimchy closed this in d442e08 Aug 20, 2013

kimchy added a commit that referenced this issue Aug 20, 2013

Bound processor size based cals to 32
We use number of processors to choose default thread pool sizes, and number of workers in networking (for HTTP and transport). Bound it to max at 32 by default as a safety measure to create too many threads.

This relates to #3478, where we set the default to 24, but 32 is probably a better default.

closes #3545

mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015

Bound processor size based cals to 32
We use number of processors to choose default thread pool sizes, and number of workers in networking (for HTTP and transport). Bound it to max at 32 by default as a safety measure to create too many threads.

This relates to elastic#3478, where we set the default to 24, but 32 is probably a better default.

closes elastic#3545

talevy added a commit to talevy/elasticsearch that referenced this issue Apr 25, 2018

add `index.lifecycle.date` setting (elastic#3545)
This PR adds a new setting called `index.lifecycle.date` that 
the ShrinkAction will be responsible for populating in the newly created index.

This way, we can continue to know when we should be executing the next phase
relative to the original index creation date, and not that of the shrunken index.

talevy added a commit to talevy/elasticsearch that referenced this issue May 14, 2018

add `index.lifecycle.date` setting (elastic#3545)
This PR adds a new setting called `index.lifecycle.date` that 
the ShrinkAction will be responsible for populating in the newly created index.

This way, we can continue to know when we should be executing the next phase
relative to the original index creation date, and not that of the shrunken index.

jasontedor added a commit that referenced this issue Aug 17, 2018

add `index.lifecycle.date` setting (#3545)
This PR adds a new setting called `index.lifecycle.date` that 
the ShrinkAction will be responsible for populating in the newly created index.

This way, we can continue to know when we should be executing the next phase
relative to the original index creation date, and not that of the shrunken index.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.