# Segments memory\_in\_bytes excessively large with allot of open indices **URL:** \ **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:** 5\ **Page:** 1
**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, 9:56am UTC](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622/1 "2016-02-01T09:56:26Z")
Hi, Ever since we moved to keeping all indices open on our ES 1.7 ELK cluster we've had a large increase in GC runs. We have 1000+ indices, mostly with 3 shards 16408 segments in total Index buffer is configured to 20% Field data cache fixed to 2GB (very questionable setting, we know) Shards get optimized to 2 segments after 1 day This is on 14 machines running 14 instances of ES with 30GB heap It seems that most memory is consumed by memory related to segments. Output from 1 node: ``` "segments" : { "count" : 1011, "memory_in_bytes" : 20007750054, "index_writer_memory_in_bytes" : 10224032, "index_writer_max_memory_in_bytes" : 6685990083, "version_map_memory_in_bytes" : 222936, "fixed_bit_set_memory_in_bytes" : 0 } ``` The mappings we use are fairly standard with a fixed number of fields. We assume disabling norms will help us a bit - is that worth considering? Anything else we could look at? ---
**Author:** ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)\ **Post date:** [February 1, 2016, 11:28am UTC](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622/2 "2016-02-01T11:28:25Z")
Hi, I can guess that it can be terms\_in\_memory. If it so, it's a trouble because I haven't got any answer how to manage this [situation](https://discuss.elastic.co/t/how-to-decrease-terms-memory-footprint/35533). In 2.x the segments memory shown in more details: > "segments": { > "count": 8337, > "memory": "7.9gb", > "memory\_in\_bytes": 8570235911, > "terms\_memory": "7.6gb", > "terms\_memory\_in\_bytes": 8190950715, > "stored\_fields\_memory": "360.9mb", > "stored\_fields\_memory\_in\_bytes": 378518192, > "term\_vectors\_memory": "0b", > "term\_vectors\_memory\_in\_bytes": 0, > "norms\_memory": "0b", > "norms\_memory\_in\_bytes": 0, > "doc\_values\_memory": "749kb", > "doc\_values\_memory\_in\_bytes": 767004, > "index\_writer\_memory": "84.9mb", > "index\_writer\_memory\_in\_bytes": 89033244, > "index\_writer\_max\_memory": "2gb", > "index\_writer\_max\_memory\_in\_bytes": 2210971648, > "version\_map\_memory": "54.5mb", > "version\_map\_memory\_in\_bytes": 57193272, > "fixed\_bit\_set": "0b", > "fixed\_bit\_set\_memory\_in\_bytes": 0 > }, How many documents in your index and how many field is indexed? ---
**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")
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. ---
**Author:** ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)\ **Post date:** [February 1, 2016, 12:37pm UTC](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622/4 "2016-02-01T12:37:04Z")
I've calculated sum of \*.tim files it's 51837 MB and terms\_in\_memory is 7812 MB. Terms in memory in 6,6 times less than total. > Wouldn't be an option at all for us, considering some indices being 100+ GB Another option is to increase number of nodes or heap memory to the infinite numbers and infinity $ 🙂 It's just too costly. The hard way is to find the place (es/lucene codec ?) and rewrite it for keeping less term in memory (which can also slows searches). ---
**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, 11:19pm UTC](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622/5 "2017-07-05T23:19:55Z")