# Elasticsearch 5.1.1 update thread\_pool setting
**URL:** https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562
**Category:** Elasticsearch
**Created:** [January 4, 2017, 2:16pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562 "2017-01-04T14:16:44Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@junior\_h](https://discuss.elastic.co/u/junior_h)
#### Post date: [January 4, 2017, 2:16pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/1 "2017-01-04T14:16:44Z")
Hi,
I've run cluster of ES 1.5 & ES 2.4 in production and ES 5.1.1 in stagging. On ES 5.1.1, I'm failed to update thread\_pool with query like:
# ================= curl -XPUT localhost:9200/\_cluster/settings -d ' { "persistent" : { "thread\_pool" : { "search" : { "queue\_size" : "300" } } } }'
It return error :
# ================= { "error": { "root\_cause": [{ "type": "illegal\_argument\_exception", "reason": "persistent setting [thread\_pool.search.queue\_size], not dynamically updateable" } ], "type": "illegal\_argument\_exception", "reason": "persistent setting [thread\_pool.search.queue\_size], not dynamically updateable" }, "status": 400 }
While, on both ES 1.5 & 2.4 thread pool setting can be update dynamically with query above (change 'thread\_pool' to 'threadpool')
I don't know whether thread pool can't be update on ES 5.1.1. Do I need to set in elasticsearch.yml on each node? Please your advice
Rgds,
---
### Author:  [@jasontedor](https://discuss.elastic.co/u/jasontedor)
#### Post date: [January 4, 2017, 2:48pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/2 "2017-01-04T14:48:01Z")
> [@junior\_h](#):
>
> I don't know whether thread pool can't be update on ES 5.1.1. Do I need to set in elasticsearch.yml on each node?
Thread pool settings are now node-level settings and are therefore not dynamically updatable. You must add these settings to your node configuration and restart for them to take effect. This is covered in the [migration docs](https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_50_settings_changes.html#_threadpool_settings).
---
### Author:  [@junior\_h](https://discuss.elastic.co/u/junior_h)
#### Post date: [January 4, 2017, 3:20pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/3 "2017-01-04T15:20:19Z")
Sadly, so adjust it will take long time especially for large cluster with big data on each node due to shard rebalancing & shard sync.
Hopefully it can be update dinamically for next version.
---
### Author:  [@jasontedor](https://discuss.elastic.co/u/jasontedor)
#### Post date: [January 4, 2017, 3:25pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/4 "2017-01-04T15:25:32Z")
> [@junior\_h](#):
>
> Sadly, so adjust it will take long time especially for large cluster with big data on each node due to shard rebalancing & shard sync.
This should not be true with delayed allocation.
> [@junior\_h](#):
>
> Hopefully it can be update dinamically for next version.
It will not.
---
### Author:  [@junior\_h](https://discuss.elastic.co/u/junior_h)
#### Post date: [January 4, 2017, 3:47pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/5 "2017-01-04T15:47:18Z")
> [@jasontedor](#):
>
> This should not be true with delayed allocation.
As far as I know, when there is update, even only index 1 document on primary shard during restarting the node, it will copy shard from primary (not the delta size).
For example, let say if the restarted node handle 3 replication shards, 10GB each. During restarting node, those primary shards receive updated query, then the node will copy 3x10GB from its primary shard, right? #CMIIW
---
### Author:  [@jasontedor](https://discuss.elastic.co/u/jasontedor)
#### Post date: [January 5, 2017, 2:26pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/6 "2017-01-05T14:26:51Z")
> [@junior\_h](#):
>
> As far as I know, when there is update, even only index 1 document on primary shard during restarting the node, it will copy shard from primary (not the delta size).
>
> For example, let say if the restarted node handle 3 replication shards, 10GB each. During restarting node, those primary shards receive updated query, then the node will copy 3x10GB from its primary shard, right?
Not quite. For example, if you [sync flush](https://www.elastic.co/guide/en/elasticsearch/reference/5.1/indices-synced-flush.html) before restarting and the sync ID is not invalided (for example, there is not another flush on the index), writes can still take place and not trigger a complete file copy during recovery if the restarted node comes back before the delayed allocation window expires. Instead, only the translog phase of recovery will be replayed which will copy the missed operations from the primary to the replica. However, if the sync ID is invalidated then a full copy is required.
Also, we are working on dramatically improving this (I literally wrote code for this this week: [https://github.com/jasontedor/elasticsearch/commit/feee9f6beda37ea109675ccf2baf05d190f8dc34](https://github.com/jasontedor/elasticsearch/commit/feee9f6beda37ea109675ccf2baf05d190f8dc34)). In the future, we will be able to do a document-based recovery meaning that we can replay all the missed operations from the primary, even if there was a flush invalidating the sync ID. For more details of the work involved see: [Add Sequence Numbers to write operations · Issue #10708 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/issues/10708)
Note the last line of the first paragraph:
> Internally we could use this ordering to speed up shard recoveries, by identifying which specific operations need to be replayed to the recovering replica instead of falling back to a file based sync.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [February 2, 2017, 2:27pm UTC](https://discuss.elastic.co/t/elasticsearch-5-1-1-update-thread-pool-setting/70562/7 "2017-02-02T14:27:08Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.