# Segments memory\_in\_bytes excessively large with allot of open indices

**URL:** <https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622>\
**Category:** Elasticsearch\
**Created:** [February 1, 2016, 9:56am UTC](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622 "2016-02-01T09:56:26Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![wvl0](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wvl0/32/6551_2.png) [@wvl0](https://discuss.elastic.co/u/wvl0)\
**Post date:** [February 1, 2016, 11:41am UTC](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622/3 "2016-02-01T11:41:11Z")

</div>

Can't verify using the API 'cause we're using 1.7. Unless ofcourse the \*.tim files on disk are fully loaded in the heap, then I could make a calculation.  
Would you mind verifying that on your cluster (du \*.tim == terms\_memory\_in\_bytes)?

Fields: anywhere between 20 and 60.  
Docs in index: anywhere between a few and 250 million

These stats are fairly broad due to us splitting various types of logging into separate indices (for various reasons).

From [How to decrease terms\_memory footprint](https://discuss.elastic.co/t/how-to-decrease-terms-memory-footprint/35533)

> As an option I can open and close older indexes at query time (open -\> search -\> close), but IMHO it's time/resource consuming decision

Wouldn't be an option at all for us, considering some indices being 100+ GB.

---

_[View the full topic](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622)._