【问题标题】:Courier Fetch: shards failedCourier Fetch:分片失败
【发布时间】:2015-07-15 05:54:00
【问题描述】:

为什么在我的弹性搜索中添加更多数据后会收到这些警告? 每次浏览仪表板时,警告都会有所不同。

“Courier Fetch:60 个分片中有 30 个失败。”

更多细节:

它是 CentOS 7.1 上的唯一节点

/etc/elasticsearch/elasticsearch.yml

index.number_of_shards: 3
index.number_of_replicas: 1

bootstrap.mlockall: true

threadpool.bulk.queue_size: 1000
indices.fielddata.cache.size: 50%
threadpool.index.queue_size: 400
index.refresh_interval: 30s

index.number_of_shards: 5
index.number_of_replicas: 1

/usr/share/elasticsearch/bin/elasticsearch.in.sh

ES_HEAP_SIZE=3G

#I use this Garbage Collector instead of the default one.

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"

集群状态

{
  "cluster_name" : "my_cluster",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 61,
  "active_shards" : 61,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 61
}

集群详情

{
  "cluster_name" : "my_cluster",
  "nodes" : {
    "some weird number" : {
      "name" : "ES 1",
      "transport_address" : "inet[localhost/127.0.0.1:9300]",
      "host" : "some host",
      "ip" : "150.244.58.112",
      "version" : "1.4.4",
      "build" : "c88f77f",
      "http_address" : "inet[localhost/127.0.0.1:9200]",
      "process" : {
        "refresh_interval_in_millis" : 1000,
        "id" : 7854,
        "max_file_descriptors" : 65535,
        "mlockall" : false
      }
    }
  }
}

我对 "mlockall" : false 很好奇,因为在 yml 上我确实写了 bootstrap.mlockall: true

日志

很多行,例如:

org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution (queue capacity 1000) on org.elasticsearch.search.action.SearchServiceTransportAction$23@a9a34f5

【问题讨论】:

    标签: elasticsearch kibana kibana-4


    【解决方案1】:

    这不适用于 elasticsearch 5.6。

    {
    "error": {
        "root_cause": [
            {
                "type": "remote_transport_exception",
                "reason": "[colmbmiscxx.xx][172.29.xx.xx:9300][cluster:admin/settings/update]"
            }
        ],
        "type": "illegal_argument_exception",
        "reason": "transient setting [threadpool.search.queue_size], not dynamically updateable"
    },
    "status": 400
    

    }

    【讨论】:

      【解决方案2】:

      当我的查询缺少结束引号时出现此错误:

      field:"value

      在我的 ElasticSearch 日志中,我看到了以下异常:

      Caused by: org.elasticsearch.index.query.QueryShardException:
          Failed to parse query [field:"value]
      ...
      Caused by: org.apache.lucene.queryparser.classic.ParseException: 
          Cannot parse 'field:"value': Lexical error at line 1, column 13.  
          Encountered: <EOF> after : "\"value"
      

      【讨论】:

      • 这是一个问题而不是一个答案?查看您正在使用的 Kibana 查询,它似乎没有正确“引用”。 Failed to parse query [field:"value]。你能提供更多细节吗?
      • 这是一个答案;此错误可能是由于查询错误而发生的,而不仅仅是 queue_size 等,就像其他答案所暗示的那样。
      • 完全正确。任何格式错误的查询都会导致在 Kibana 上打印此警告
      【解决方案3】:

      从 Elasticsearch >= 版本 5 开始,无法使用 _cluster/settings API 更新 thread_pool.search.queue_size 的集群设置。在我的情况下,更新 ElasticSearch 节点 yml 文件也不是一个选项,因为如果节点失败,那么自动缩放代码将为其他 ES 节点带来默认的 yml 设置。

      我有一个包含 3 个节点的集群,并且有 400 个活动主分片和 7 个活动线程,队列大小为 1000。随着查询水平分布到更多可用节点,将具有类似配置的节点数量增加到 5 个已经解决了这个问题。

      【讨论】:

        【解决方案4】:

        使用 Elasticsearch 5.4 的 thread_pool 有个下划线吧。

        thread_pool.search.queue_size: 10000
        

        请参阅Elasticsearch Thread Pool module documentation 上的文档

        【讨论】:

          【解决方案5】:

          我同意@Philip 的观点,但是至少在Elasticsearch >=1.5.2 上需要重启elasticsearch,因为可以动态设置threadpool.search.queue_size

          curl -XPUT http://your_es:9200/_cluster/settings
          {
              "transient":{
                  "threadpool.search.queue_size":10000
              }
          }
          

          【讨论】:

          • 使用 Elasticsearch >= 版本 5,这是不可能的 - discuss.elastic.co/t/…。您必须使用 yaml 配置文件。
          【解决方案6】:

          对我来说,调整线程池搜索 queue_size 解决了这个问题。我尝试了许多其他方法,这就是解决它的方法。

          我将此添加到我的 elasticsearch.yml

          threadpool.search.queue_size: 10000
          

          然后重启elasticsearch。

          推理...(来自文档)

          一个节点拥有多个线程池以改进线程的方式 内存消耗在节点内进行管理。许多这样的游泳池也 有与之关联的队列,允许挂起的请求 持有而不是丢弃。

          特别是搜索...

          用于计数/搜索操作。默认为固定大小为 int((# available_processors * 3) / 2) + 1,queue_size 为 1000。

          更多信息可以参考elasticsearchdocs here...

          我在查找此信息时遇到了麻烦,因此我希望这对其他人有所帮助!

          【讨论】:

          • 感谢它对我有用。配置键是 thread_pool.search.queue_size 不是 threadpool.search.queue_size
          【解决方案7】:

          这可能表明您的集群运行状况存在问题。在不了解您的集群的情况下,无话可说。

          【讨论】:

          • 我不知道我的集群的哪些细节可能有助于解决这个问题。有任何想法吗?它只是一个唯一的节点。我将在问题中添加更多细节。
          • 您将需要显示集群状态、分配给集群的内存、可用的文件描述符、操作系统等。还要查看 elasticsearch 日志以查看是否有任何明显的情况(例如内存不足,打开的文件太多等)
          • 我添加了更多细节。关于这些异常,也许我需要在 yml 文件中增加一些线程池或其他内容。感谢您的帮助。
          • 同样在单节点系统上,拥有副本是没有意义的,因为分片永远不会被分配,因此您可能希望将索引映射更新为具有 0 个副本(这是您可以更改的设置)。另外你有两次index.number_of_shards,这意味着将使用第二个值(尽管在创建索引后它并不重要)
          • 谢谢,我用这个解决了这个问题:#don't use all processor processor: 6 threadpool: get: type: fixed size: 30 queue_size: 3000 search: type: fixed size: 30 queue_size: 3000 index.number_of_shards: 2 index.number_of_replicas: 0
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2022-01-16
          • 2017-12-02
          • 2018-02-11
          • 2014-02-17
          • 2013-04-20
          • 2021-12-29
          • 2015-07-06
          相关资源
          最近更新 更多