# Query Failures from Data Too Large and High Memory Pressure

**URL:** https://discuss.elastic.co/t/query-failures-from-data-too-large-and-high-memory-pressure/29489
**Category:** Elasticsearch
**Created:** [September 17, 2015, 3:19pm UTC](https://discuss.elastic.co/t/query-failures-from-data-too-large-and-high-memory-pressure/29489 "2015-09-17T15:19:44Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![kellymmg](https://avatars.discourse-cdn.com/v4/letter/k/e79b87/32.png) [@kellymmg](https://discuss.elastic.co/u/kellymmg)
#### Post date: [September 17, 2015, 3:19pm UTC](https://discuss.elastic.co/t/query-failures-from-data-too-large-and-high-memory-pressure/29489/1 "2015-09-17T15:19:44Z")

</div>

We recently spun up a cluster on Found Elasticsearch and have been experiencing a high number of errors. After running our index for a while, we noticed two things:

1. Our memory pressure is essentially pegged at 99% on two out of three nodes

2. Almost all queries are now failing with an error about a field having data size too large:

> ElasticsearchException[org.elasticsearch.common.breaker.CircuitBreakingException: [FIELDDATA] Data too large, data for [name.name\_sortable] would be larger than limit of [2508954009/2.3gb]]; nested: UncheckedExecutionException[org.elasticsearch.common.breaker.CircuitBreakingException: [FIELDDATA] Data too large, data for [name.name\_sortable] would be larger than limit of [2508954009/2.3gb]]; nested: CircuitBreakingException[[FIELDDATA] Data too large, data for [name.name\_sortable] would be larger than limit of [2508954009/2.3gb]]; }{[AB082J7RSqG2KV7Zu3zaSg][ali-production][3]: RemoteTransportException[[instance-0000000001][inet[/172.17.0.7:19326]][indices:data/read/search[phase/query]]]; nested: QueryPhaseExecutionException[[ali-production][3]: query[filtered(filtered(+(phone\_numbers.phone\_numbers\_prefix:cb  
> phone\_numbers.phone\_numbers\_literal:CB  
> name:cb  
> email\_domain:CB))-\>+cache(company\_id:`\b\u0000\u0000=\u001C) +NotFilter(cache(is_deleted:T)) +cache(_type:organization))->cache(org.elasticsearch.index.search.nested.NonNestedDocsFilter@eed9ba48)],from[0],size[3],sort [<custom:\"name.name_sortable\": org.elasticsearch.index.fielddata.fieldcomparator.BytesRefFieldComparatorSource@75cbfa>!,<custom:\"entity_id\": org.elasticsearch.index.fielddata.fieldcomparator.LongValuesComparatorSou rce@449c175f>!]: Query Failed [Failed to execute main query]]; nested: ElasticsearchException[org.elasticsearch.common.breaker.CircuitBreakingException: [FIELDDATA] Data too large, data for [name.name_sortable] would b e larger than limit of [2508954009/2.3gb]]; nested: UncheckedExecutionException[org.elasticsearch.common.breaker.CircuitBreakingException: [FIELDDATA] Data too large, data for [name.name_sortable] would be larger than limit of [2508954009/2.3gb]]; nested: CircuitBreakingException[[FIELDDATA] Data too large, data for [name.name_sortable] would be larger than limit of [2508954009/2.3gb]]; }{[AB082J7RSqG2KV7Zu3zaSg][ali-production][4]: RemoteTransportException[[instance-0000000001][inet[/172.17.0.7:19326]][indices:data/read/search[phase/query]]]; nested: QueryPhaseExecutionException[[ali-production][4]: query[filtered(filtered(+(phone_numbers.phone_ numbers_prefix:cb phone_numbers.phone_numbers_literal:CB name:cb email_domain:CB))->+cache(company_id:`\b\u0000\u0000=\u001C) +NotFilter(cache(is\_deleted:T)) +cache(\_type:organization))-\>cache(org.elasticsearch.index.search.nested.NonNestedDocsFilter@eed9ba48)],from[0],size[3],sort  
> [\<custom:"name.name\_sortable": org.elasticsearch.index.fielddata.fieldcomparator.BytesRefFieldComparatorSource@1dbcc2c0\>!,\<custom:"entity\_id": org.elasticsearch.index.fielddata.fieldcomparator.LongValuesComparatorS  
> ource@22b3649\>!]: Query Failed [Failed to execute main query]]; nested: ElasticsearchException[org.elasticsearch.common.breaker.CircuitBreakingException: [FIELDDATA] Data too large, data for [entity\_id] would be larger  
> than limit of [2508954009/2.3gb]]; nested: UncheckedExecutionException[org.elasticsearch.common.breaker.CircuitBreakingException: [FIELDDATA] Data too large, data for [entity\_id] would be larger than limit of [2508954  
> 009/2.3gb]]; nested: CircuitBreakingException[[FIELDDATA] Data too large, data for [entity\_id] would be larger than limit of [2508954009/2.3gb]]; }]","status":500}, /app/vendor/bundle/ruby/2.1.0/gems/elasticsearch-tran  
> sport-1.0.12/lib/elasticsearch/transport/transport/base.rb:135:in `__raise_transport_error' /app/vendor/bundle/ruby/2.1.0/gems/elasticsearch-transport-1.0.12/lib/elasticsearch/transport/transport/base.rb:227:in `perform\_request'

We don't believe this particular setup has a remarkably large data set as we have a parallel cluster hosted elsewhere, but we can't seem to figure out how to solve this issue. The "entity\_id" column mentioned in the error is an integer field, so I'm not sure how it could get to be larger than 2.3 gb.

The stats to our index don't seem to be particularly interesting, but I can provide them if they can provide any clues. Any help would be appreciated.

---

<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: [July 5, 2017, 11:49pm UTC](https://discuss.elastic.co/t/query-failures-from-data-too-large-and-high-memory-pressure/29489/2 "2017-07-05T23:49:43Z")

</div>


