# Hyperthreading effects on Elasticsearch performance

**URL:** <https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402>\
**Category:** Elasticsearch\
**Created:** [March 24, 2023, 12:12am UTC](https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402 "2023-03-24T00:12:35Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vadym](https://avatars.discourse-cdn.com/v4/letter/v/8baadc/32.png) [@Vadym](https://discuss.elastic.co/u/Vadym)\
**Post date:** [March 24, 2023, 12:12am UTC](https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402/1 "2023-03-24T00:12:35Z")

</div>

Hi team,

What's the current recommendations regarding Hyper Threading with Elasticsearch, do we get any benefits and are there any downsides to keep HT enabled?

I've seen multiple performance tests documents which claim that Elasticsearch gains around 10% performance boost from enabled HT. Is this still true in 2023 on ES 7.17+ are there recommendations supported by community?

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [March 24, 2023, 12:32am UTC](https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402/2 "2023-03-24T00:32:41Z")

</div>

Hyper threading generally results in an overall performance benefit if you’re running a single node per machine. The absolute figures are entirely dependent on the use case, hardware, working set size, etc. so it’s impossible to say without benchmarking.

Hyper threading can be a disadvantage if you’re trying to run multiple nodes on a single machine (e.g containers), because Linux CPU quotas are not hyper threading aware.

Again, this is general advice and you are best off testing yourself on your hardware and workload.

---

<div class="post-metadata">

**Author:** ![Vadym](https://avatars.discourse-cdn.com/v4/letter/v/8baadc/32.png) [@Vadym](https://discuss.elastic.co/u/Vadym)\
**Post date:** [March 24, 2023, 1:52am UTC](https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402/3 "2023-03-24T01:52:23Z")

</div>

Thank you Warkolm, did you run any benchmarks yourself to test this? Do you think general 10% increase is close to reality?

We run baremetal. Thought to compare how much extra performance we can get from the HT compared with adding extra nodes.

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [March 24, 2023, 3:39am UTC](https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402/4 "2023-03-24T03:39:48Z")

</div>

Me, no. I asked some of our performance team about this which is where I got that response. Further to that;

We don’t/haven’t done any specific analysis of hyper threading except for the Linux CFS CPU quota stuff.

We noticed that two equal size ESS nodes performed differently if one was on an an existing host that was \>50% total CPU util and the other wasn’t. This was because all hardware threads are fully utilized and any extra cpu time is now “a logical thread”, meaning that their compute power is not equal.

---

<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:** [April 21, 2023, 3:40am UTC](https://discuss.elastic.co/t/hyperthreading-effects-on-elasticsearch-performance/328402/5 "2023-04-21T03:40:41Z")

</div>

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