Courier Fetch:分片失败

时间:2015-05-05 13:10:33

标签: elasticsearch kibana kibana-4

为什么在向elasticsearch添加更多数据后会收到这些警告? 每次浏览仪表板时警告都不同。

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

Example 1

Example 2

更多详情:

它是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

7 个答案:

答案 0 :(得分:24)

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

我将此添加到我的elasticsearch.yml

threadpool.search.queue_size: 10000

然后重新启动elasticsearch。

推理......(来自文档)

  

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

特别是搜索...

  

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

有关详细信息,请参阅elasticsearch docs here ...

我很难找到这些信息,所以我希望这有助于其他人!

答案 1 :(得分:7)

使用Elasticsearch 5.4 thread_pool有一个下划线。

thread_pool.search.queue_size: 10000

请参阅Elasticsearch Thread Pool module documentation

上的文档

答案 2 :(得分:4)

这可能表明群集的运行状况存在问题。如果不了解有关您的群集的更多信息,可以说更多。

答案 3 :(得分:3)

当我的查询缺少结束语时,我收到此错误:

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"

Courier Fetch: 5 of 35 shards failed.

在我的ElasticSearch日志中,我看到了以下例外情况:

{{1}}

答案 4 :(得分:1)

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

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

答案 5 :(得分:0)

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

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

答案 6 :(得分:0)

这不适用于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

}