# JVM heap over time graphs
**URL:** https://discuss.elastic.co/t/jvm-heap-over-time-graphs/166553
**Category:** Elasticsearch
**Created:** [January 31, 2019, 12:49pm UTC](https://discuss.elastic.co/t/jvm-heap-over-time-graphs/166553 "2019-01-31T12:49:35Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@juka](https://discuss.elastic.co/u/juka)
#### Post date: [January 31, 2019, 12:49pm UTC](https://discuss.elastic.co/t/jvm-heap-over-time-graphs/166553/1 "2019-01-31T12:49:35Z")
I have a question regarding the JVM Heap Space over time. There is a wonderful documentation about that here:
> **[A Heap of Trouble: Managing Elasticsearch's Managed Heap
| Elastic](https://www.elastic.co/blog/a-heap-of-trouble)**
>
> A Heap of Trouble Engineers can resist anything except giving their processes more resources: bigger, better, faster, more of cycles, cores, RAM, disks and interconnects! When these resources are not ...
but it does not show how the JVM Heap Space should look like in an ideal setup.
We are running Elasticsearch on Bluemix Kubernetes and have 18 Nodes. There is a curl command querying elasticsearch for the max heapPercent variable in the /\_cat/nodes API every 15 minutes and our graphs look like this for a four hour timeframe:
According to the documentation from the top, the up and down indicates too much heap but we also have nodes that are flat and all share the same configuration. The flatliners are master and data nodes alike and so are the ones that go up and down.
Occasionally we get GC INFO messages in the gc.log and elastic.log files:
[INFO][o.e.m.j.JvmGcMonitorService] [master-node-x] [gc][419468] overhead, spent [255ms] collecting in the last [1s]
Do you have any documentation or thoughts on that?
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [February 28, 2019, 12:49pm UTC](https://discuss.elastic.co/t/jvm-heap-over-time-graphs/166553/2 "2019-02-28T12:49:35Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.