# Degraded Indexing Performance on v7.3.1 (from v5.6.10)

**URL:** <https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062>\
**Category:** Elasticsearch\
**Created:** [February 26, 2020, 3:07pm UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062 "2020-02-26T15:07:40Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jack\_Farrelly](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jack_farrelly/32/63353_2.png) [@Jack\_Farrelly](https://discuss.elastic.co/u/Jack_Farrelly)\
**Post date:** [February 26, 2020, 3:07pm UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/1 "2020-02-26T15:07:40Z")

</div>

Hey,

We recently upgraded from ES version 5.6.10 to 7.3.1 and noticed indexing performance seems much worse. We could index at a rate of around 500k op/s, and now we peak at around 200k op/s.

During indexing, we get bulk request thread rejections, but we are actually only utilising around 50% of our available CPU, and it seems we are not able to increase the thread pool size because of this limit here: [https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/threadpool/ExecutorBuilder.java#L52](https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/threadpool/ExecutorBuilder.java#L52)

Our use case is that we only reindex clusters that don't receive live traffic, so I don't think this limit really makes sense for us. I wondered what the reasoning behind it was, and if other people have the same issue? I assume if we could increase the thread pool size, we would be able to utilise ~100% of CPU for indexing.

**Steps to reproduce** :

1. Reindex a cluster with enough writes per second to get bulk thread rejections
2. Check if CPU is actually maxing out
3. In our case, we're only using 50% CPU

Cheers!  
Jack

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [February 26, 2020, 6:01pm UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/2 "2020-02-26T18:01:41Z")

</div>

Are you indexing new documents only or do you also update existing documents? What does disk I/O and iowait look like? How many indices and shards are you actively indexing into?

---

<div class="post-metadata">

**Author:** ![Jack\_Farrelly](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jack_farrelly/32/63353_2.png) [@Jack\_Farrelly](https://discuss.elastic.co/u/Jack_Farrelly)\
**Post date:** [February 27, 2020, 3:38pm UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/3 "2020-02-27T15:38:30Z")

</div>

1. We are indexing all new documents
2. Disk IO utilisation is around 10%, and CPU wait IO is \<0.3 (the machines have 32 cores)
3. We're indexing into 15 primary shards and it's all 1 single index

And in this case we're using about 50% CPU of the cluster. But increasing the number of bulk requests will start to cause thread rejections.

---

<div class="post-metadata">

**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\
**Post date:** [February 27, 2020, 5:14pm UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/4 "2020-02-27T17:14:29Z")

</div>

Why didn't you update to the latest version? At least to 7.5

---

<div class="post-metadata">

**Author:** ![Jack\_Farrelly](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jack_farrelly/32/63353_2.png) [@Jack\_Farrelly](https://discuss.elastic.co/u/Jack_Farrelly)\
**Post date:** [February 28, 2020, 1:03am UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/5 "2020-02-28T01:03:29Z")

</div>

7.3.1 was the latest version when we upgraded 🙂

Besides, this limitation is still there in recent versions.

I see that it's reading `node.processors` setting to configure the thread pool limit...is it possible to override the number of available processors in the elasticsearch config somehow?

---

<div class="post-metadata">

**Author:** ![Jack\_Farrelly](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jack_farrelly/32/63353_2.png) [@Jack\_Farrelly](https://discuss.elastic.co/u/Jack_Farrelly)\
**Post date:** [February 28, 2020, 1:11am UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/6 "2020-02-28T01:11:36Z")

</div>

Ah found it, the parameter is just `processors` in 7.3.1  
Seems a bit hacky to have to fake the number of available processors to increase this limit, but hey ho.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [March 27, 2020, 1:11am UTC](https://discuss.elastic.co/t/degraded-indexing-performance-on-v7-3-1-from-v5-6-10/221062/7 "2020-03-27T01:11:40Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.