SearchContextMissingException

SearchContextMissingException

Cluser:我正在将Elasticsearch 1.3.1与不同服务器中的6个节点一起使用,这些节点均通过LAN连接。带宽很高,每个都有45 GB的RAM。

配置我们分配给节点运行的堆大小为10g。除了唯一的发现,群集名称,节点名称和我们2区域外,我们确实具有elasticsearch默认配置。 3个节点属于一个区域,另一个属于另一个区域。

索引:15,索引的总大小为76GB。

现在,我面对着SearchContextMissingException异常作为DEBUG日志。闻起来有些搜索查询已花费了很多时间。但是我检查了查询,没有查询对集群产生大量负载...我想知道为什么会这样。

问题:由于此问题,所有节点都开始一个一个地收集GC。并导致OOM :(

这是我的异常(exception)。请给我解释两件事。

  • 什么是SearchContextMissingException?为什么会发生?
  • 如何防止此类查询出现在集群中?

  • 错误:
    [YYYY-MM-DD HH:mm:ss,039][DEBUG][action.search.type ] [es_node_01] [5031530]
       Failed to execute fetch phase
       org.elasticsearch.transport.RemoteTransportException: [es_node_02][inet[/1x.x.xx.xx:9300]][search/phase/fetch/id]
       Caused by: org.elasticsearch.search.SearchContextMissingException: No search context found for id [5031530]
           at org.elasticsearch.search.SearchService.findContext(SearchService.java:480)
           at org.elasticsearch.search.SearchService.executeFetchPhase(SearchService.java:450)
           at org.elasticsearch.search.action.SearchServiceTransportAction$SearchFetchByIdTransportHandler.messageReceived(SearchServiceTransportAction.java:793)
           at org.elasticsearch.search.action.SearchServiceTransportAction$SearchFetchByIdTransportHandler.messageReceived(SearchServiceTransportAction.java:782)
           at org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:275)
           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
           at java.lang.Thread.run(Thread.java:722)
    

    最佳答案

    如果可以,请更新至1.4.2。它修复了一些已知的弹性问题,包括您描述的级联故障。

    无论如何,默认配置肯定会给您带来麻烦。最低要求,您可能需要考虑设置断路器,例如现场数据缓存。

    这是我们的生产配置摘要。我假设您还正确配置了Linux文件句柄限制:see here

    # prevent swapping
    bootstrap.mlockall: true
    
    indices.breaker.total.limit: 70%
    indices.fielddata.cache.size: 70%
    
    # make elasticsearch work harder to migrate/allocate indices on startup (we have a lot of shards due to logstash); default was 2
    cluster.routing.allocation.node_concurrent_recoveries: 8
    
    # enable cors
    http.cors.enabled: true
    http.cors.allow-origin: /https?:\/\/(localhost|kibana.*\.linko\.io)(:[0-9]+)?/
    
    index.query.bool.max_clause_count: 4096
    

    10-06 01:06