# Inter-thread-pool concurrency

**URL:** <https://discuss.elastic.co/t/inter-thread-pool-concurrency/89920>\
**Category:** Elasticsearch\
**Created:** [June 19, 2017, 11:39am UTC](https://discuss.elastic.co/t/inter-thread-pool-concurrency/89920 "2017-06-19T11:39:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zline](https://avatars.discourse-cdn.com/v4/letter/z/e5b9ba/32.png) [@Zline](https://discuss.elastic.co/u/Zline)\
**Post date:** [June 19, 2017, 11:39am UTC](https://discuss.elastic.co/t/inter-thread-pool-concurrency/89920/1 "2017-06-19T11:39:25Z")

</div>

Hello,

I see in the docs that some thread pools have size greater or equal to # of available processors. That totally makes sense in case of mainly-indexing or mainly-searching workload - all CPU resources are utilized. But what about cases such as indexing + searching. I suppose there would be at least (2 \* # of available processors) runnable threads which leads to lots of context switches and degraded performance. Given that I think eventually ES would benefit of using thread scheduler which keeps number of runnable threads close to # of available processors. A good example might be Hadoop fair scheduler (although it schedules not threads but processes cluster-wide). Are my reasonings correct?

Thanks.

p.s. presuming I/O is handled by separate threads and we're speaking about CPU-bound workload.

---

<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:** [July 17, 2017, 11:39am UTC](https://discuss.elastic.co/t/inter-thread-pool-concurrency/89920/2 "2017-07-17T11:39:35Z")

</div>

Closed on July 17, 2017, 11:39am UTC

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