1
votes

I run the query below on a large elastic search cluster. The cluster bcomes unresponsive

{
  "size": 10000,
  "query": {
    "bool": {
      "must": [
        {
          "regexp": {
            "message": {
              "value": ".*exception.*"
            }
          }
        },
        {
          "bool": {
            "should": [
              {
                "term": {
                  "beat.hostname": "ip-xxx-xx-xx-xx"
                }
              }
            ]
          }
        },
        {
          "range": {
            "@timestamp": {
              "lt": 1518459660000,
              "format": "epoch_millis",
              "gte": 1518459600000
            }
          }
        }
      ]
    }
  }
}

When I remove the wildcarded .*exception.* and replace it with any non wildcarded string like xyz it returns fast. Though the query uses a wildcarded expression, it also looks for a small time range and a specific host. I would think this is a very simple query. Any reason why elasticsearch server can't handle this query? The cluster has 10 nodes and 20 TB of data.

1
Have you tried with .*?exception.*? It should be more efficient (and same what you want).Gábor Bakos
Thanks @GáborBakos I will try that. Besides that do you see anything wrong with the querySriram
` .*?exception.*? ` does not do any better.Sriram

1 Answers

0
votes

See the documentation for Regexp Query. It clearly states the following:

Note: The performance of a regexp query heavily depends on the regular expression chosen. Matching everything like .* is very slow

What would be ideal is to change the text analysis on the message field with a WordDelimiterTokenFilter and set split_on_case_change to true. Then something like NullPointerException will get indexed as three separate tokens [Null, Pointer, Exception]. This can help you search on exception without using a regex. Caveat is you need to reindex all your documents.

Another quick thing to try might be to keep your filter conditions on the hostname and timestamp in a filter context, which will prefilter documents before running your regexp query. This may be a short-term solution for you until you fix the text analysis.