# Need Help: Upgrade of ES + Large queries = new CPU overload

**URL:** <https://discuss.elastic.co/t/need-help-upgrade-of-es-large-queries-new-cpu-overload/19555>\
**Category:** Elasticsearch\
**Created:** [September 1, 2014, 2:50pm UTC](https://discuss.elastic.co/t/need-help-upgrade-of-es-large-queries-new-cpu-overload/19555 "2014-09-01T14:50:35Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Scott\_Decker](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@Scott\_Decker](https://discuss.elastic.co/u/Scott_Decker)\
**Post date:** [September 1, 2014, 2:50pm UTC](https://discuss.elastic.co/t/need-help-upgrade-of-es-large-queries-new-cpu-overload/19555/1 "2014-09-01T14:50:35Z")

</div>

Hey all,  
We have been testing the new 1.3.1 release on our current load and  
queries, and have found that under same conditions, same queries, the es  
cluster we have just starts to max out cpu and the thread pools fill up and  
the query times just keep going up until eventually we have the restart  
nodes just to clear things.  
on our older (.20.6) version, we do have big queries. Think 100+ terms, but  
they were all wrapped in a filter and cached. We almost never did any  
scoring, and if we did, it was only on a few terms.  
so, a query may look like the following:

"query": {  
"filtered": {  
"query": {  
"constant\_score": {  
"query": {  
"bool": {  
"must": [  
{  
"bool": {  
"should": {  
"bool": {  
"should": [  
{  
"term": {  
"content": "smyrna"  
}  
},  
{  
"term": {  
"title": "smyrna"  
}  
}  
]  
}  
}  
}  
}  
]  
}  
},  
"boost": 1  
}  
},  
"filter": {  
"bool": {  
"must": [  
{  
"bool": {  
"must": [  
{  
"bool": {  
"must": {  
"bool": {  
"should": [  
{  
"bool": {  
"must": [  
{  
"terms": {\<fill in long lists of ids  
here}

```
and this filter is broken up into multiple sections, each filter is 

```

given a cache name and cache key

so, what could have changed between .20.6 and 1.3.1 that would cause this  
sort of non-scored filter query to suddenly spend so much cpu time running?  
i did a thread dump and it is setting multiple threads in the .scorer state  
of the filteredquery.  
not sure if that matters.

any help in trying to figure out where the es is spending its time on all  
of this would be helpful. we at least have marvel up and running now and  
that tells us that cpu gets pegged and the avg query times, but not sure  
how to start debugging the query side to see could be changed under the  
hoods to cause such a drastic change.

Thanks,  
Scott

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/be45cf36-3b4a-4452-b3bc-461a879dec02%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/be45cf36-3b4a-4452-b3bc-461a879dec02%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Scott\_Decker](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@Scott\_Decker](https://discuss.elastic.co/u/Scott_Decker)\
**Post date:** [September 1, 2014, 6:13pm UTC](https://discuss.elastic.co/t/need-help-upgrade-of-es-large-queries-new-cpu-overload/19555/2 "2014-09-01T18:13:19Z")

</div>

well, in case anyone wants to know, it was because we had  
\_cache:true  
and  
\_cache\_key:

items in our filter sets.  
basically because they are known filters that do not change.

for some reason, having this set caused huge amounts of cpu usage. not sure  
what was happening behind the scenes, but this was our culprit. will have  
to look into the code and see what causes this to cause such an issue.

On Monday, September 1, 2014 7:50:35 AM UTC-7, Scott Decker wrote:

> Hey all,  
> We have been testing the new 1.3.1 release on our current load and  
> queries, and have found that under same conditions, same queries, the es  
> cluster we have just starts to max out cpu and the thread pools fill up and  
> the query times just keep going up until eventually we have the restart  
> nodes just to clear things.  
> on our older (.20.6) version, we do have big queries. Think 100+ terms,  
> but they were all wrapped in a filter and cached. We almost never did any  
> scoring, and if we did, it was only on a few terms.  
> so, a query may look like the following:
> 
> "query": {  
> "filtered": {  
> "query": {  
> "constant\_score": {  
> "query": {  
> "bool": {  
> "must": [  
> {  
> "bool": {  
> "should": {  
> "bool": {  
> "should": [  
> {  
> "term": {  
> "content": "smyrna"  
> }  
> },  
> {  
> "term": {  
> "title": "smyrna"  
> }  
> }  
> ]  
> }  
> }  
> }  
> }  
> ]  
> }  
> },  
> "boost": 1  
> }  
> },  
> "filter": {  
> "bool": {  
> "must": [  
> {  
> "bool": {  
> "must": [  
> {  
> "bool": {  
> "must": {  
> "bool": {  
> "should": [  
> {  
> "bool": {  
> "must": [  
> {  
> "terms": {\<fill in long lists of ids  
> here}
> 
> ```
> and this filter is broken up into multiple sections, each filter is 
> 
> ```
> 
> given a cache name and cache key
> 
> so, what could have changed between .20.6 and 1.3.1 that would cause this  
> sort of non-scored filter query to suddenly spend so much cpu time running?  
> i did a thread dump and it is setting multiple threads in the .scorer  
> state of the filteredquery.  
> not sure if that matters.
> 
> any help in trying to figure out where the es is spending its time on all  
> of this would be helpful. we at least have marvel up and running now and  
> that tells us that cpu gets pegged and the avg query times, but not sure  
> how to start debugging the query side to see could be changed under the  
> hoods to cause such a drastic change.
> 
> Thanks,  
> Scott

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/19fee079-ce3e-4e77-a4b4-7e95c35f9d98%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/19fee079-ce3e-4e77-a4b4-7e95c35f9d98%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<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 6, 2017, 1:05am UTC](https://discuss.elastic.co/t/need-help-upgrade-of-es-large-queries-new-cpu-overload/19555/3 "2017-07-06T01:05:04Z")

</div>

Closed on July 6, 2017, 1:05am UTC