# Optimal configuration of the ES cluster

**URL:** <https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825>\
**Category:** Elasticsearch\
**Created:** [September 8, 2020, 6:58am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825 "2020-09-08T06:58:38Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![IliaIsakhin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/iliaisakhin/32/75238_2.png) [@IliaIsakhin](https://discuss.elastic.co/u/IliaIsakhin)\
**Post date:** [September 8, 2020, 6:58am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/1 "2020-09-08T06:58:38Z")

</div>

Hello!

My ES 7.8.0 cluster contains 5 nodes with 120 GB heap memory and 32 CPU in it. Also, I have pretty large index with 6.6kk docs and, according to _\_cat/indices/_ API, with store.size 59.8gb and pri.store.size 30.1gb. Number of primary shards is 3 and replicas is 1. Is it optimal number for shards? I read that every shard should contain ~ 30GB of data

In the same time every node of my cluster is master, data and ingest - is it ok, or I must configure it like 3 master-nodes and 2 data-nodes? Currently, I'm ok with search speed and availability of the cluster. In addition to that periodically I'm catching warning in log file about

> took [17.6s], which is over [10s], to compute cluster state update for [put-mapping

I think it is strange due to quite good resources that I gave to my cluster.

Thank you!

---

<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:** [September 8, 2020, 7:14am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/2 "2020-09-08T07:14:14Z")

</div>

It looks like you either have very large or constantly expanding mappings, which is causing updates to be slow. How many fields does your index have? Have you overridden any of the default settings?

Are you you using parent-child or nested mappings?

---

<div class="post-metadata">

**Author:** ![IliaIsakhin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/iliaisakhin/32/75238_2.png) [@IliaIsakhin](https://discuss.elastic.co/u/IliaIsakhin)\
**Post date:** [September 8, 2020, 8:07am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/3 "2020-09-08T08:07:31Z")

</div>

I have 2 dynamic mappings with path match and no nested or parent-child mappings.  
My settings endpoint returns

```auto
search": {
      "max_buckets": "100000",
      "default_keep_alive": "1m",
      "max_keep_alive": "5m"
 }

```

Also my _\_mappings_ endpoint returns quite a big json due to dynamic mappings.

---

<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:** [September 8, 2020, 8:09am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/4 "2020-09-08T08:09:17Z")

</div>

How many fields do you have in your mappings? Have you overridden the default limit?

---

<div class="post-metadata">

**Author:** ![IliaIsakhin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/iliaisakhin/32/75238_2.png) [@IliaIsakhin](https://discuss.elastic.co/u/IliaIsakhin)\
**Post date:** [September 8, 2020, 8:22am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/5 "2020-09-08T08:22:59Z")

</div>

```auto
"index.mapping.total_fields.limit": 200000

```

Yes, we have this index setting

---

<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:** [September 8, 2020, 8:37am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/6 "2020-09-08T08:37:01Z")

</div>

That does not sound like a good setting value and will most likely cause problems. No wonder mapping changes result in slow cluster state updates as these are performed in a single thread.

I can think of no easy fix, so suspect you may either need to live with this or reconsider how you handle mappings to avoid this.

---

<div class="post-metadata">

**Author:** ![IliaIsakhin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/iliaisakhin/32/75238_2.png) [@IliaIsakhin](https://discuss.elastic.co/u/IliaIsakhin)\
**Post date:** [September 8, 2020, 8:46am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/7 "2020-09-08T08:46:42Z")

</div>

Alright, got it, thank you for the answer!  
Could you also please give advice about nodes roles and shards sizes for data like in my situation?

---

<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:** [September 8, 2020, 9:36am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/8 "2020-09-08T09:36:40Z")

</div>

Your problem seems to be with the mappings and not necessarily with shard size or distribution. Have never seen a use case with even close to that level of mapped fields so have no advice to give. This is unchartered territory as far as I know.

---

<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:** [October 6, 2020, 9:36am UTC](https://discuss.elastic.co/t/optimal-configuration-of-the-es-cluster/247825/9 "2020-10-06T09:36:53Z")

</div>

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