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

Jump to bottom

Bound processor size based cals to 32 #3545

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

Bound processor size based cals to 32 #3545

kimchy opened this issue Aug 20, 2013 · 0 comments
Labels
>enhancement v0.90.4 v1.0.0.Beta1

Comments

@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 as completed in d442e08 Aug 20, 2013
kimchy added a commit that referenced this issue Aug 20, 2013
@kimchy
Bound processor size based cals to 32
5d3ba04 
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
@kimchy
Bound processor size based cals to 32
4d33a5e 
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
@talevy
add index.lifecycle.date setting (elastic#3545)
34d6b61 
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
@talevy
add index.lifecycle.date setting (elastic#3545)
5c9c272 
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 pushed a commit that referenced this issue Aug 17, 2018
@talevy @jasontedor
add index.lifecycle.date setting (#3545)
1a32f0c 
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
Assignees
No one assigned
Labels
>enhancement v0.90.4 v1.0.0.Beta1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@kimchy