# Elasticsearch 1.4.2 JVM memory leak? **URL:** \ **Category:** Elasticsearch\ **Created:** [April 6, 2015, 4:13am UTC](https://discuss.elastic.co/t/elasticsearch-1-4-2-jvm-memory-leak/23104 "2015-04-06T04:13:17Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Abhishek\_Andhavarapu](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/abhishek_andhavarapu/32/782_2.png) [@Abhishek\_Andhavarapu](https://discuss.elastic.co/u/Abhishek_Andhavarapu)\ **Post date:** [April 6, 2015, 4:13am UTC](https://discuss.elastic.co/t/elasticsearch-1-4-2-jvm-memory-leak/23104/1 "2015-04-06T04:13:17Z")
Hi, We have about 30 node elasticsearch cluster. We often run in to out of memory issue and when I look in the JVM memory which is usually around 75-80% which is 24-25 gigs of 30 gigs heap. The filter cache and field cache add to up 5GB on a node, I'm trying to understand whats the other 15-20GB in the heap. We have 10% caps for filter and field cache. What could be the other 15-20Gb in the heap ? We are on es 1.4.2 are there are any know memory leaks ? Couldn't these be the objects waiting for garbage collection ? If not how would I know ? Thanks, Abhishek -- 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/795be77d-4f30-4b2f-8ab9-6ca938616c0e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/795be77d-4f30-4b2f-8ab9-6ca938616c0e%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![mjdude5](https://avatars.discourse-cdn.com/v4/letter/m/6bbea6/32.png) [@mjdude5](https://discuss.elastic.co/u/mjdude5)\ **Post date:** [April 6, 2015, 5:55pm UTC](https://discuss.elastic.co/t/elasticsearch-1-4-2-jvm-memory-leak/23104/2 "2015-04-06T17:55:08Z")
How many shards and segments do you have? I believe both shards and segments require memory, for segments merging them can reduce the memory footprint. Are you graphing your heap usage? I think what's useful is looking at the max(min(heap)) over a few days, assuming you're using the 75% oldgen threshold you'll see the heap usage reduce significantly when it runs. That baseline memory usage is useful to know. On Monday, April 6, 2015 at 12:13:17 AM UTC-4, Abhishek Andhavarapu wrote: > Hi, > > We have about 30 node elasticsearch cluster. We often run in to out of > memory issue and when I look in the JVM memory which is usually around > 75-80% which is 24-25 gigs of 30 gigs heap. The filter cache and field > cache add to up 5GB on a node, I'm trying to understand whats the other > 15-20GB in the heap. We have 10% caps for filter and field cache. What > could be the other 15-20Gb in the heap ? We are on es 1.4.2 are there are > any know memory leaks ? Couldn't these be the objects waiting for garbage > collection ? If not how would I know ? > > Thanks, > Abhishek -- 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/c7e26604-2efa-4872-8ae7-2052b1d845d4%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c7e26604-2efa-4872-8ae7-2052b1d845d4%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 12:21am UTC](https://discuss.elastic.co/t/elasticsearch-1-4-2-jvm-memory-leak/23104/3 "2017-07-06T00:21:24Z")