# JVM HEAP usage over 85% during snapshots

**URL:** <https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568>\
**Category:** Elasticsearch\
**Created:** [August 9, 2019, 8:04am UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568 "2019-08-09T08:04:24Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![cyril.r](https://avatars.discourse-cdn.com/v4/letter/c/96bed5/32.png) [@cyril.r](https://discuss.elastic.co/u/cyril.r)\
**Post date:** [August 9, 2019, 8:04am UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568/1 "2019-08-09T08:04:24Z")

</div>

Hello 🙂

I have an issue with elasticsearch and HEAP usage during snapshots.

My cluster have 7 nodes (2cpu & 7.5G of RAM per node, local SSD storage), about 220 millions of documents for a total size of 377GB worth of data (reported by Kibana).  
I'm running version 5.5.2 (I Know it is EOL but that's what I'm stuck with).

I'm currently implementing hourly snapshots to a s3 bucket.

While everything is working fine, during the snapshot the JVM heap rises over 85%, triggering our monitoring system.

I have set the heap size to 50% of my available RAM according to the manual, so I think configuration is good.

I attached a capture of one node during the snapshot.

I'm strugling to find something to do to prevent such JVP HEAP spikes.

Is it dangerous (can crash the cluster/node)?  
What can I do about this?

Thanks for your help 🙂

 ![es_heap_snapshot](https://us1.discourse-cdn.com/elastic/original/3X/9/d/9d2b4f79525854a707ec3f2b02f3f0472e725a05.png)

Regards

---

<div class="post-metadata">

**Author:** ![cyril.r](https://avatars.discourse-cdn.com/v4/letter/c/96bed5/32.png) [@cyril.r](https://discuss.elastic.co/u/cyril.r)\
**Post date:** [August 12, 2019, 7:52am UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568/2 "2019-08-12T07:52:44Z")

</div>

Hi there,

Any advices? 🙂

---

<div class="post-metadata">

**Author:** ![cyril.r](https://avatars.discourse-cdn.com/v4/letter/c/96bed5/32.png) [@cyril.r](https://discuss.elastic.co/u/cyril.r)\
**Post date:** [August 26, 2019, 9:06am UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568/3 "2019-08-26T09:06:56Z")

</div>

Hi,

Still no clue on what's happening, no one has experienced this behavior?

---

<div class="post-metadata">

**Author:** ![elemus](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/elemus/32/61976_2.png) [@elemus](https://discuss.elastic.co/u/elemus)\
**Post date:** [August 26, 2019, 8:19pm UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568/4 "2019-08-26T20:19:26Z")

</div>

I've already experimented issues like you but I'm reading about it, I think we need to explicit say to elasticsearch clean jvm after snapshots, but I'm reading about it.

---

<div class="post-metadata">

**Author:** ![cyril.r](https://avatars.discourse-cdn.com/v4/letter/c/96bed5/32.png) [@cyril.r](https://discuss.elastic.co/u/cyril.r)\
**Post date:** [August 27, 2019, 7:28am UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568/5 "2019-08-27T07:28:00Z")

</div>

Yes, Ram usage after snapshot returns to normal but what is worrying me is Ram usage when snapshot is launched.

Since it reach \> 85%, my fear is that it kills the node or slow down the whole cluster.  
I already saw our cluster slowed down to a halt just because of one unhealty node, so I'm not verry confident about this happening.

What are my options to have hourly backups of our cluster if snapshotting causes a risk?

---

<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:** [September 24, 2019, 7:28am UTC](https://discuss.elastic.co/t/jvm-heap-usage-over-85-during-snapshots/194568/6 "2019-09-24T07:28:02Z")

</div>

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