Based on the version you're running I suggest you investigate whether possibly related to SOLR-13336 [1].
Particularly vulnerable configs would have query-time WordDelimiter[Graph]Filter configured to split and catenate, or Synonym[Graph]Filter with multi-term synonyms. [1] https://issues.apache.org/jira/browse/SOLR-13336 On Fri, May 27, 2022 at 9:36 AM Vincenzo D'Amore <[email protected]> wrote: > > For my understanding there is no such thing like a feature that kills a > specific query that would cause an OOM. > Either in Solr or in general in any other search engine. > I suggest you start investigating if Solr memory is enough for the kind of > queries you have, then try to understand what query is dangerous (in terms > of memory allocation) and why. > > > > On Fri, May 27, 2022 at 12:15 PM Parag Ninawe <[email protected]> > wrote: > > > Hi, > > > > We are currently using Solr 7.7 in Cloud mode > > The issues we are facing is with Search queries where it takes down > > the solr processes with JVM OOM issues. > > > > A recent incident we faced where a single search query with multiple > > boosted fields in the query, took down the solr process with > > out-of-memory issue. > > I understand there is a proactive way to check such scenarios and > > never let them happen at the first place but in our case, > > possibilities are kind of endless at the moment and the Search queries > > are not completely in our control > > > > I was thinking if there would be some feature which can kill the > > specific query which would cause OOM, so that, we can avoid the Solr > > processes going down, but seems such inbuilt feature is not present > > currently in Solr > > > > Looking for some help if anyone has built something around it or if > > someone has done anything to reduce such scenarios > > > > I am open to any ideas or suggestions in this matter, Our end goal is > > to avoid the case where Solr process goes down with OOM due to > > resource hungry Search queries > > Any help or direction towards this matter would be immensely helpful > > > > > > Thanks, > > > > Parag > > > > > -- > Vincenzo D'Amore
