# Sizing master-only nodes

**URL:** <https://discuss.elastic.co/t/sizing-master-only-nodes/24997>\
**Category:** Elasticsearch\
**Created:** [July 6, 2015, 10:47pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997 "2015-07-06T22:47:24Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![lucien](https://avatars.discourse-cdn.com/v4/letter/l/278dde/32.png) [@lucien](https://discuss.elastic.co/u/lucien)\
**Post date:** [July 6, 2015, 10:47pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/1 "2015-07-06T22:47:24Z")

</div>

We are planning to shift from an architecture where all nodes are node.data=true and node.master=true to a system with dedicated data and master nodes. Is there any rule of thumb for sizing the master nodes? What I can find online suggests "lightweight" ([https://www.elastic.co/guide/en/elasticsearch/reference/1.6/modules-node.html](https://www.elastic.co/guide/en/elasticsearch/reference/1.6/modules-node.html)) or "small", but I haven't found any indication of whether this is small in processing or memory, and what this size is small relative to.

Our data consists of many indices, most of which are quite small, with a single shard and a single replica, currently running on 4 nodes, each with 4 CPUs and 34 GB memory.  
"number\_of\_nodes": 4,  
"number\_of\_data\_nodes": 4,  
"active\_primary\_shards": 5927,  
"active\_shards": 11854,

---

<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:** [July 7, 2015, 3:25am UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/2 "2015-07-07T03:25:29Z")

</div>

I'd personally go no lower than 4GB of heap.  
However you can also increase the heap to 75% of system for a master node as you don't need to worry about any file system caching.

So you can easily go for 3 x 6GB nodes.

---

<div class="post-metadata">

**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\
**Post date:** [July 7, 2015, 3:46am UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/3 "2015-07-07T03:46:58Z")

</div>

Agreed with Mark. You will need to ensure you take care of availability in ur new configuration. If u go with one dedicated master and if that leaves cluster / restarts / crashes / etc. ur cluster will not be available. If you select 2 master there is a concern of split-brain. Also the more the number of shards, the more the size of your cluster state be.

---

<div class="post-metadata">

**Author:** ![pranav.shukla](https://avatars.discourse-cdn.com/v4/letter/p/848f3c/32.png) [@pranav.shukla](https://discuss.elastic.co/u/pranav.shukla)\
**Post date:** [April 15, 2016, 12:30pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/4 "2016-04-15T12:30:14Z")

</div>

We are planning to use 3 master-only nodes for our cluster + 4 data nodes spread across two availability zones in the same region on EC2.

Is there a recommended topology of how to place master-only nodes across the two AZs?

Can we live with instance-store based storage for master-only node or we should go for durable EBS backed nodes?

Any best-practices / reference will be appreciated.

---

<div class="post-metadata">

**Author:** ![vangap](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vangap/32/44927_2.png) [@vangap](https://discuss.elastic.co/u/vangap)\
**Post date:** [November 4, 2016, 11:21am UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/5 "2016-11-04T11:21:40Z")

</div>

@warkolm is there any rationale behind the 4 GB?

what operations does a master node do for it to require 4 GB?  
Other than cluster state becoming huge, there isn't anything that requires more memory than the basic requirement for running JVM I suppose?

Thanks.

---

<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:** [November 4, 2016, 10:51pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/6 "2016-11-04T22:51:13Z")

</div>

That's just field experience really.

> [@vangap](#):
>
> Other than cluster state becoming huge, there isn't anything that requires more memory than the basic requirement for running JVM I suppose?

Exactly.  
And if you give it 3GB of the 4GB you should have _more_ than enough room. As you allude, if you run into problems with that much heap on a master only node then you have other issues.

---

<div class="post-metadata">

**Author:** ![vangap](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vangap/32/44927_2.png) [@vangap](https://discuss.elastic.co/u/vangap)\
**Post date:** [November 5, 2016, 12:33pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/7 "2016-11-05T12:33:05Z")

</div>

Thanks @warkolm

The reason I asked is because I have been using a cluster of t2.micros for master nodes for some time now, with 500 MB heap.

My cluster state sits at about couple of MB.

So, I was wondering if there is a risk involved in using such smaller machines.

---

<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:** [November 5, 2016, 9:02pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/8 "2016-11-05T21:02:38Z")

</div>

I'd be cautious about the lack of CPU resources, large mapping updates or other things may cause your cluster to become unstable.

---

<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, 10:06pm UTC](https://discuss.elastic.co/t/sizing-master-only-nodes/24997/9 "2017-07-05T22:06:21Z")

</div>


