# Slow increase in memory pressure **URL:** \ **Category:** Elasticsearch\ **Created:** [June 27, 2016, 9:43pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084 "2016-06-27T21:43:12Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![afaraone](https://avatars.discourse-cdn.com/v4/letter/a/6de8d8/32.png) [@afaraone](https://discuss.elastic.co/u/afaraone)\ **Post date:** [June 27, 2016, 9:43pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/1 "2016-06-27T21:43:12Z")
Over the past two weeks, the memory pressure on our prod cluster has been slowly ramping up higher and higher. we passed 74% last week, and are in the 80s as I write this. We are using upserts because come documents can get updates from two places, and we have a job that will update the previous night's worth of records once each. I understand that updates cause dirty memory, but am not sure how to try and battle the issue on an ongoing basis. ---
**Author:** ![alexbrasetvik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alexbrasetvik/32/15538_2.png) [@alexbrasetvik](https://discuss.elastic.co/u/alexbrasetvik)\ **Post date:** [June 27, 2016, 9:52pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/2 "2016-06-27T21:52:48Z")
If memory pressure is above 75%, I'd advice upgrading the cluster. If you want input on how to optimise to reduce overall memory usage, that's a generic Elasticsearch question better fit for the [Elasticsearch-forum](https://discuss.elastic.co/c/elasticsearch). ---
**Author:** ![afaraone](https://avatars.discourse-cdn.com/v4/letter/a/6de8d8/32.png) [@afaraone](https://discuss.elastic.co/u/afaraone)\ **Post date:** [June 27, 2016, 10:22pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/3 "2016-06-27T22:22:42Z")
moved from the cloud-elasticsearch forum. I'm not sure how to diagnose how to move forward. it seems like the fielddata usage of the cluster is high (about 12Gigabytes, currently). Im not sure if i can manually evict the memory, or if there are other ways to approach this problem. currently my batch size for the upserts i mentioned is 1000. not sure if changing that would help, setting fielddata config, or both. also not sure on how to prioritize making those changes ---
**Author:** ![ravitandur](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ravitandur/32/4568_2.png) [@ravitandur](https://discuss.elastic.co/u/ravitandur)\ **Post date:** [June 28, 2016, 8:19am UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/4 "2016-06-28T08:19:32Z")
We can evict the filed data memory using below rest API: [http://ESHOST:9200/\_cache/clear](http://ESHOST:9200/_cache/clear) [USE POST method with below body] { "fielddata": "true" } This will clear the filed data cache, but again it will be filled up gradually. The resolve this issue permanently you can use doc\_value for all the fields [which should not be analyzed] on which you need to apply aggregations ... etc. Hope this helps. ---
**Author:** ![afaraone](https://avatars.discourse-cdn.com/v4/letter/a/6de8d8/32.png) [@afaraone](https://discuss.elastic.co/u/afaraone)\ **Post date:** [June 28, 2016, 2:36pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/5 "2016-06-28T14:36:24Z")
wll evicting the field data have any effect on the cluster itself? or will the operation be seamless? this is a prod system, so i want to be able to make changes without affecting accessibility to the data. thanks a bunch for your help! ---
**Author:** ![ravitandur](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ravitandur/32/4568_2.png) [@ravitandur](https://discuss.elastic.co/u/ravitandur)\ **Post date:** [June 28, 2016, 2:46pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/6 "2016-06-28T14:46:34Z")
No impact on cluster original data. Only filed data cache will be cleaned. You can also check, which filed is using max heap using : [http://localhost:9200/\_cat/fielddata?v&fields=\*?pretty&human](http://localhost:9200/_cat/fielddata?v&fields=*?pretty&human) After clearing the filed data, the subsequent aggregations might be slow, as it needs to created the cache again for the field required. As I mentioned, if you use doc\_values, we can get rid of this field data cache issue permanently. ---
**Author:** ![afaraone](https://avatars.discourse-cdn.com/v4/letter/a/6de8d8/32.png) [@afaraone](https://discuss.elastic.co/u/afaraone)\ **Post date:** [June 28, 2016, 9:08pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/7 "2016-06-28T21:08:09Z")
Is the issue with fielddata exacerbated by having a lot of indexes or shards? currently we're splitting data into monthly indexes with 24 shards each. we have close to 4 years of data this way. Someone has already mentioned to me that the number or shards seems high, so im curious if this could be related? ---
**Author:** ![afaraone](https://avatars.discourse-cdn.com/v4/letter/a/6de8d8/32.png) [@afaraone](https://discuss.elastic.co/u/afaraone)\ **Post date:** [July 26, 2016, 8:31pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/8 "2016-07-26T20:31:41Z")
Looking for a little bit more help with this. Currently the Heap usage is around 90-95%. not sure if there is some particular settings that are misaligned in our cluster, but any help would be appreciated. evicting fielddata helped for a while, but usage is back up, and im looking for other ways to bring down the bottom line on memory usage. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:32pm UTC](https://discuss.elastic.co/t/slow-increase-in-memory-pressure/54084/9 "2017-07-05T22:32:41Z")