# Different load on nodes

**URL:** <https://discuss.elastic.co/t/different-load-on-nodes/123228>\
**Category:** Elasticsearch\
**Created:** [March 9, 2018, 9:01am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228 "2018-03-09T09:01:35Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mats990](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mats990/32/37516_2.png) [@mats990](https://discuss.elastic.co/u/mats990)\
**Post date:** [March 9, 2018, 9:01am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228/1 "2018-03-09T09:01:36Z")

</div>

Hi,

We had more load on our cluster than usual and at that time we noticed some strange behavior. A node that hold primaries had much higher GC count. All nodes have the same configuration, JVM: 1.8.0\_162 ES: 5.6.4. The only difference between node #1 and node #4 was that #1 had 2 primaries while #4 had 2 replicas. All shards have roughly the same size (~5GB).  
Is it possible that node that holds primaries have higher memory consumption that one that holds only replicas?

Screenshots from cerebro and grafana:  
 ![New photo by Matija Bruncic](https://lh3.googleusercontent.com/hFXCwpBWcKpmMYhMTnuN-ov94zbLrEptrASBCDt249Usk27iHFRQMkGuRBAvxCYVWa8BPfqiOBl7rQl61_1S03q5dbXerw0Flc8b4J6jNxLq55j2H37J9gbjPLGyhyn4FTY0eVnw5g=w600-h315-p-k)  
 ![New photo by Matija Bruncic](https://lh3.googleusercontent.com/J62RoimDBmPkS9OBrHAeH4ocDkGr-ZWR7Zz5coB8jFd5-nQ5ScrW90Y4OxpeZ8L7X7d01ooRVV80wBQymnO3xrpJveJowtF8oclUedrKTdaSeSgzcuy37d3TldhJOi0Y_SsIH9UV1A=w600-h315-p-k)

---

<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:** [March 9, 2018, 9:08am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228/2 "2018-03-09T09:08:03Z")

</div>

Are you performing lots of updates, e.g. using scripts?

---

<div class="post-metadata">

**Author:** ![mats990](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mats990/32/37516_2.png) [@mats990](https://discuss.elastic.co/u/mats990)\
**Post date:** [March 9, 2018, 9:26am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228/3 "2018-03-09T09:26:25Z")

</div>

Hi Christian,

That's correct, we use scripted update in each request

---

<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:** [March 9, 2018, 9:51am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228/4 "2018-03-09T09:51:42Z")

</div>

Scripted updates are performed on the primary, and the resulting document is then replicated, meaning that the script processing is likely to result in more GC on the node with more primary shards.

---

<div class="post-metadata">

**Author:** ![mats990](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mats990/32/37516_2.png) [@mats990](https://discuss.elastic.co/u/mats990)\
**Post date:** [March 9, 2018, 10:35am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228/5 "2018-03-09T10:35:25Z")

</div>

Great, thx. That explains a lot.  
Is there maybe a feature to "force" even distribution of primary shards across the nodes? In our case, I'd like to have primary for shard #3 on node #4. It doesn't have to be automatic, maybe we can add a feature in our service to watch for that kind of state and manually promote replica shards

---

<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 6, 2018, 10:35am UTC](https://discuss.elastic.co/t/different-load-on-nodes/123228/6 "2018-04-06T10:35:36Z")

</div>

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