# Context Suggester: FST size estimate (RAM)

**URL:** <https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642>\
**Category:** Elasticsearch\
**Created:** [October 20, 2020, 6:57am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642 "2020-10-20T06:57:49Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bhavik92](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bhavik92/32/50344_2.png) [@Bhavik92](https://discuss.elastic.co/u/Bhavik92)\
**Post date:** [October 20, 2020, 6:57am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/1 "2020-10-20T06:57:49Z")

</div>

I've heard about the high memory (heap) occupancy in case FST.  
Is there any thumb rule I can use to calculate the size of FST / heap given the amount of data that'll be fed as input to suggester. Any benchmarking studies focussing on this is also welcome.

This will help us decide between completion suggester and other less memory intensive approaches.

We're trying to evaluate completion suggester for our use-case. The fields to autocomplete are short, consisting of 4 words maximum  
We're tokenizing them ourselves at indexing time and indexing the array as input so as to support search on any token (not just the prefix)

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [October 21, 2020, 8:22am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/2 "2020-10-21T08:22:47Z")

</div>

It depends on how you are using the completion suggester, but there is an easy way to monitor its size by using [index stats](https://www.elastic.co/guide/en/elasticsearch/reference/7.9/indices-stats.html#index-stats-api-path-params).

---

<div class="post-metadata">

**Author:** ![Bhavik92](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bhavik92/32/50344_2.png) [@Bhavik92](https://discuss.elastic.co/u/Bhavik92)\
**Post date:** [October 21, 2020, 6:41pm UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/3 "2020-10-21T18:41:12Z")

</div>

Hey @spinscale .. Thanks for reply !

We're just enabling completion on one field which can consist of maximum 4 words and we also limit max\_input\_length to 50 chars.

I checked the node stats as well as index stats for "completion" field.  
The node stats clearly mention that "size in bytes" is memory usage (not disk)..  
However, for index stats, I'm not sure whether "size in bytes" means RAM / disk.  
It was 96 MB for a single shard. (192 MB for index with 2 shards)

We had 10 indices on which I had indexed a completion field. These 10 are just clones of each other. I only use 1 of them for my queries.  
However, each of them is occupying the same amount in memory.. Does this mean that there is no optimization based on frequency of usage ?  
All indices FSTs are always kept in memory ?  
And I also see that this number cleanly doubles because of 2 shards per index too.

I'd assume that if it is memory, it's probably all in heap although heap stats don't have breakup of completion related fields.

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [October 22, 2020, 9:46am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/4 "2020-10-22T09:46:46Z")

</div>

Indeed, FST are kept in memory in the heap (loaded from disk). There is no optimization based on usage, this data structure exists as is, independent from your usage.

---

<div class="post-metadata">

**Author:** ![Bhavik92](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bhavik92/32/50344_2.png) [@Bhavik92](https://discuss.elastic.co/u/Bhavik92)\
**Post date:** [October 26, 2020, 7:14am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/6 "2020-10-26T07:14:23Z")

</div>

Thanks for clarification @spinscale  
So I read through all the metrics again and my understanding is that metrics with just " **size\_in\_bytes**" are actually disk size metrics while metrics with " **memory**" in name like "memory\_in\_bytes", "terms\_memory\_in\_bytes" are RAM metrics.  
Going by that logic, since "completion" field has just "size\_in\_bytes", it should be the disk metric right ? (Or I am wrong)  
If it is disk size metric, I did not find any metric with "memory" in name that could correspond to just "completion". I can see "terms\_memory\_in\_bytes",  
"stored\_fields\_memory\_in\_bytes",  
"term\_vectors\_memory\_in\_bytes",  
"norms\_memory\_in\_bytes" but they don't seem to be specific to completion. Could u lead me to the memory metric for that.

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [October 26, 2020, 9:03am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/7 "2020-10-26T09:03:24Z")

</div>

Hey,

so when digging through the code, this is loading the FST data structure in heap and then using that for the size calculation. So this is indeed memory based.

--Alex

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 23, 2020, 9:03am UTC](https://discuss.elastic.co/t/context-suggester-fst-size-estimate-ram/252642/8 "2020-11-23T09:03:38Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
