# Indexing time issue after upgrading 7.7.1 to 7.10.1

**URL:** <https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777>\
**Category:** Elasticsearch\
**Created:** [January 21, 2021, 12:16pm UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777 "2021-01-21T12:16:07Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Evgeny\_Dekhtyarev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/evgeny_dekhtyarev/32/82652_2.png) [@Evgeny\_Dekhtyarev](https://discuss.elastic.co/u/Evgeny_Dekhtyarev)\
**Post date:** [January 21, 2021, 12:16pm UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777/1 "2021-01-21T12:16:07Z")

</div>

Hello everyone!

Thanks for your product!  
We have several Elasticsearch clusters and one of them has a problem when upgrading from 7.7.1 to 7.10.1.  
We needed an update due to a problem with the circuit breaker ([https://github.com/elastic/elasticsearch/pull/59394](https://github.com/elastic/elasticsearch/pull/59394))

We use Elasticsearch as a database for searching and displaying data.  
Our environment:

- Elasticsearch is running in docker (in k8s), image [docker.elastic.co/elasticsearch/elasticsearch-oss](http://docker.elastic.co/elasticsearch/elasticsearch-oss)
- Exporter metrics justwatch/elasticsearch\_exporter:1.1.0
- Load Profile: ~ 2000-3000 bulk (batch 200) inserts data at each node and 150-200 read requests to each node.
- 3 servers (8 CPU (`Xeon E3-1240 v6 3.7Ghz`) / 64 Gb RAM / 4x480 Gb SSD (JBOD)).
- 1 server (16 CPU (`Xeon E-2288G 3.7Ghz`) / 64 Gb RAM / 4x480 Gb SSD (JBOD)).
- POD limits: `memory 52Gi && cpu 8`
- heap: `-Xmx32127m -Xms32127m`
- 1 main index (most active): 80 Gb for 3 shards. 2 replicas for each shard.

Main problem:

- After updating ES to 7.10.1, indexing time increased several times, which led to product problems (we do not have time to update data in elasticsearch) and almost all server resources were consumed.  
 ![indexingTimeCompare](https://us1.discourse-cdn.com/elastic/original/3X/4/f/4fc1a62da539c93dcd0d3a8dc87e57e5d5a4597c.png)

This is how the cpu load looks like:

 ![CPUCompare](https://us1.discourse-cdn.com/elastic/original/3X/f/4/f4adf6dcf728b8fd83b1cad56a4ff3d03715aa30.png)

From the application side, nothing has changed. The application profile with ES has not changed.  
For the last week we have been investigating the problem and cannot find a solution to this question: so that the indexing time returns to its previous values.

The only thing we noticed - it is a serious change of memory used for index segments:

 ![segmentsMemorySizeCompare](https://us1.discourse-cdn.com/elastic/original/3X/7/8/78e333d11c1618754d6975c922cb82792108c2f8.png)

Displayed metric: elasticsearch\_indices\_segments\_memory\_bytes  
But we did not find how we can influence this metric in order to try to return it to its old values or to see the influence of its changes on it.

* * *

Please help in the analysis of this problem.

- How can we affect elasticsearch\_indices\_segments\_memory\_bytes?
- Maybe we needed to bring specific changes to elasticsearch after upgrading to version 7.10.1?
- Maybe we need to provide more information on our configuration / load to understand the problem?

Thank you.

---

<div class="post-metadata">

**Author:** ![Evgeny\_Dekhtyarev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/evgeny_dekhtyarev/32/82652_2.png) [@Evgeny\_Dekhtyarev](https://discuss.elastic.co/u/Evgeny_Dekhtyarev)\
**Post date:** [January 27, 2021, 7:51am UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777/2 "2021-01-27T07:51:29Z")

</div>

@warkolm hi!

Can you help me with this topic?  
Or suggest - can anyone help me?

---

<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:** [January 27, 2021, 7:54am UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777/3 "2021-01-27T07:54:57Z")

</div>

> [@Evgeny\_Dekhtyarev](#):
>
> heap: `-Xmx32127m -Xms32127m`

This should be set to around 30GB in order to benefit from compressed pointers. Please see [this blog post](https://www.elastic.co/blog/a-heap-of-trouble) for further details. It is recommended that the heap is set no larger than 50% of available RAM, which in your case would be 26GB.

---

<div class="post-metadata">

**Author:** ![Evgeny\_Dekhtyarev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/evgeny_dekhtyarev/32/82652_2.png) [@Evgeny\_Dekhtyarev](https://discuss.elastic.co/u/Evgeny_Dekhtyarev)\
**Post date:** [January 27, 2021, 9:25am UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777/4 "2021-01-27T09:25:20Z")

</div>

@Christian_Dahlqvist, thanks for the suggestion!

Compressed pointers work, but improvements are not visible - the use of the CPU and the indexing time did not change ☹

---

<div class="post-metadata">

**Author:** ![Evgeny\_Dekhtyarev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/evgeny_dekhtyarev/32/82652_2.png) [@Evgeny\_Dekhtyarev](https://discuss.elastic.co/u/Evgeny_Dekhtyarev)\
**Post date:** [February 12, 2021, 5:22am UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777/5 "2021-02-12T05:22:51Z")

</div>

Nobody has such problems on the latest versions of Elasticsearch?

---

<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 12, 2021, 5:23am UTC](https://discuss.elastic.co/t/indexing-time-issue-after-upgrading-7-7-1-to-7-10-1/261777/6 "2021-03-12T05:23:18Z")

</div>

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