# Heap Usage in ES Nodes **URL:** \ **Category:** Elasticsearch\ **Created:** [November 29, 2013, 6:28am UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643 "2013-11-29T06:28:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![ananth](https://avatars.discourse-cdn.com/v4/letter/a/dfb087/32.png) [@ananth](https://discuss.elastic.co/u/ananth)\ **Post date:** [November 29, 2013, 6:28am UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643/1 "2013-11-29T06:28:18Z")
We have 10 data-nodes in ES cluster. Each have the following configuration , - 8 GB out of 16 GB - default indexing buffer size (10% of heap) - ## indices.store.throttle.type: merge ## indices.store.throttle.max\_bytes\_per\_sec: 50mb ## index.cache.field.max\_size: 1000mb ## index.cache.field.expire: 15m index.store.type: mmapfs So far we are only doing indexing alone. No search queries are executed in ES data-nodes. Our data-nodes heap usage crosses 5 GB, we took heap dump and analysed. In that we saw unreachable objects took nearly 3 GB (Kindly look at attachment). The rest 2 GB is occupied by RobinEngine instances which is acceptable due to BloomFilter used for primary key look up. My question are , - Though we set mmap as store type what actually occupies in that 3 GB ? among 3GB, byte[] took 750 MB what will we stored in byte[] ? - Whether mmap will used while segments merges ? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/8c5e8360-69cd-4951-8fcb-de7ba727843b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8c5e8360-69cd-4951-8fcb-de7ba727843b%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![ananth](https://avatars.discourse-cdn.com/v4/letter/a/dfb087/32.png) [@ananth](https://discuss.elastic.co/u/ananth)\ **Post date:** [December 4, 2013, 12:03pm UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643/2 "2013-12-04T12:03:29Z")
can anyone has any idea on this ? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c160d4c0-a015-4d99-8b32-735bdde9e327%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c160d4c0-a015-4d99-8b32-735bdde9e327%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [December 4, 2013, 12:48pm UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643/3 "2013-12-04T12:48:45Z")
mmap is not related to objects on the JVM heap. It has also not much to do with segment merge. Think of mmap as an efficient method to address file reads, outside of the scope of the JVM. It is related to virtual memory organization of the OS. byte[] is holding "raw" data of the Lucene index, when segments got to be processed. Jörg -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoED%3DBHjorBhVXFzyS9uJRRRWAGUSNgDQSHT5w7p4GUWag%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoED%3DBHjorBhVXFzyS9uJRRRWAGUSNgDQSHT5w7p4GUWag%40mail.gmail.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![ananth](https://avatars.discourse-cdn.com/v4/letter/a/dfb087/32.png) [@ananth](https://discuss.elastic.co/u/ananth)\ **Post date:** [December 9, 2013, 5:18am UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643/4 "2013-12-09T05:18:32Z")
Hi Jörg , Thanks for your reply. Each data node has approximately 350-400 shards. We are creating daily indexes , thus indexing will happen only on limited number of shards on each node. We are maintaining indexes for only limited days say 15-20. Each time we saw few GB's of un-reachable objects almost on all data nodes in their heap dumps. As i mentioned in the following post our nodes are getting quitted due to long GC pauses. [https://groups.google.com/forum/#!searchin/elasticsearch/Anantha/elasticsearch/X6aIjk8wCQw/LT0BE\_ipmMYJ](https://groups.google.com/forum/#!searchin/elasticsearch/Anantha/elasticsearch/X6aIjk8wCQw/LT0BE_ipmMYJ) Jörg, any suggestions will help us to resolve the memory problem. I think it might be due to segment merges, correct me if i am wrong ! -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/74ef5c54-9129-4e97-92a8-8543669fe0b3%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/74ef5c54-9129-4e97-92a8-8543669fe0b3%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [December 9, 2013, 8:42am UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643/5 "2013-12-09T08:42:41Z")
If you use index.cache.field.expire, you are activating expiration control. I don't know if this is very useful. Maybe this creates many additional unreachable objects but I'm not sure. Jörg -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHxzcNcppq\_P2Gmw962FzajX5nQ0-WxN2SHc1SbsBteYQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHxzcNcppq_P2Gmw962FzajX5nQ0-WxN2SHc1SbsBteYQ%40mail.gmail.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:02am UTC](https://discuss.elastic.co/t/heap-usage-in-es-nodes/14643/6 "2017-07-06T02:02:34Z")
Closed on July 6, 2017, 2:02am UTC