# High CPU & high IOPS on StressTest

**URL:** https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253
**Category:** Elasticsearch
**Created:** [March 2, 2016, 1:31pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253 "2016-03-02T13:31:42Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![radap](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radap/32/8037_2.png) [@radap](https://discuss.elastic.co/u/radap)
#### Post date: [March 2, 2016, 1:31pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/1 "2016-03-02T13:31:42Z")

</div>

I recently have upgraded my ES from 1.5.2 to 2.2.0 version and add Shield to it. I`m trying to perform a stress test by using [Locust](http://locust.io/) that blast the cluster with data (by nodejs app).  
I got strange results comparing to the previous stress test (on 1.5.2):

```
		1.5.2 ver 2.2.0 ver

cpu 50% avg, 90% peak	87% avg, 96% peak

IOPS 30 avg, 300 peak	800 avg, 1122 peak

```

Why ES working so hard?

Another strange thing that I cant understand, and I think is connected to the above, is the output in plugin head.  
Previously (1.5.2) I saw indices store data as:

> Index\_name  
> size: 10.3Gi (20.6Gi)  
> docs: 17,073,010 (17,073,010)

But now (2.2.0) it is as:

> Index\_name  
> size: 13.7Gi (29.3Gi)  
> docs: 10,217,220 (20,434,440)

As you can see, the data double itself in ES 2.2.0, why it is happening?  
There something wrong with my v2.2.0 ES configurations?

---

<div class="post-metadata">

### Author: ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)
#### Post date: [March 2, 2016, 2:26pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/2 "2016-03-02T14:26:28Z")

</div>

Hi! Would you show your index mapping?

My guess is:  
Your index have replicas so you get double size in documents and disk usage (from head plugin). As for CPU if you don't disable doc\_values in mapping template (as for 2.x it's enabled by default, that gives increase in CPU%, disk space, IOPS). As for IOPS increase it's may be combination of doc\_values and synced flush of translog (enabled by default).

---

<div class="post-metadata">

### Author: ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)
#### Post date: [March 2, 2016, 2:32pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/3 "2016-03-02T14:32:46Z")

</div>

Agreeing with the points @rusty raised: Doc values on by default adds some CPU/IO overhead and some more disk space, translog flushes on every action now (instead of every 5s) and the replica issue.

In addition to that, there was a change at the Lucene layer. Incoming blob of text, but the tl;dr is that Lucene identifies idle resources and utilizes them, making the resource usage look higher when it's really just getting work done faster.

So, in Elasticsearch 1.x, we forcefully throttled Lucene's segment merging process to prevent it from over-saturating your nodes/cluster.

The problem is that a strict threshold is almost never the right answer. If you are indexing heavily, you often want to increase the threshold to let Lucene use all your CPU and Disk IO. If you aren't indexing much, you likely want the threshold lower. But you also want it to be able to "burst" the limit for one-off merges when your cluster is relatively idle.

In Lucene 5.x (used in ES 2.0+), they added a new style of merge throttling that monitors how active the index is, and automatically adjusts the throttle threshold (see [https://issues.apache.org/jira/browse/LUCENE-6119](https://issues.apache.org/jira/browse/LUCENE-6119), [https://github.com/elastic/elasticsearch/pull/9243](https://github.com/elastic/elasticsearch/pull/9243) and [https://github.com/elastic/elasticsearch/pull/9145](https://github.com/elastic/elasticsearch/pull/9145)).

In practice, what this means is that your indexing tends to be faster in ES 2.0+ because segments are allowed to merge as fast as your cluster can handle, without over-saturating your cluster. But it also means that your cluster will happily use any idle resources, which is why you see more resource utilization.

Basically, Lucene identified that those resources weren't being used...so it put them to work to finish the task faster. 🙂

---

<div class="post-metadata">

### Author: ![radap](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radap/32/8037_2.png) [@radap](https://discuss.elastic.co/u/radap)
#### Post date: [March 2, 2016, 2:59pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/4 "2016-03-02T14:59:18Z")

</div>

Hi! 🙂  
I didn't mentioned it, but yes, I do have replicas.  
So, to get it straight, doc\_values were disabled by default in elastic 1.5.x?

---

<div class="post-metadata">

### Author: ![radap](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radap/32/8037_2.png) [@radap](https://discuss.elastic.co/u/radap)
#### Post date: [March 2, 2016, 3:00pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/5 "2016-03-02T15:00:29Z")

</div>

Very interesting, Thank You!

---

<div class="post-metadata">

### Author: ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)
#### Post date: [March 2, 2016, 3:01pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/6 "2016-03-02T15:01:32Z")

</div>

> [@radap](#):
>
> So, to get it straight, doc\_values were disabled by default in elastic 1.5.x?

Yes it were.

---

<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 5, 2017, 11:12pm UTC](https://discuss.elastic.co/t/high-cpu-high-iops-on-stresstest/43253/7 "2017-07-05T23:12:00Z")

</div>


