ES常见问题整理

Posted lwhctv

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ES常见问题整理相关的知识,希望对你有一定的参考价值。

1、集群状态red、yellow处理方法

1.red表示主分片数据不完整,通常时由于某个索引的主分片为分片unassigned,找出这个分片未分配的原因,解决即可;

curl -XGET http://{ESIP}:9200/_cluster/health?level=indices

2.yellow表示所有主分片可用,但副本分片不完整,最常见的情景是单节点时,由于es默认是有1个副本,主分片和副本不能在同一个节点上,所以副本就是未分配unassigned;

2、elasticsearch出现unassigned shards的原因排查

1.原因:造成未分配的分片原因有很多,具体看每一次未分配的具体情况,ES使用? Cluster Allocation Explain API,会返回集群为什么不分配分片的详细原因,照返回的结果,进行有针对性的解决。

2.举例:ES集群出现unassigned shards,导致集群变黄,执行Cluster Allocation Explain API,返回结果如下:

"reason" : "CLUSTER_RECOVERED","explanation" : "too many shards [6] allocated to this node for index [bot-audio-upload-2020.02.10], index setting [index.routing.allocation.total_shards_per_node=6]"

从返回我们看到集群默认index.routing.allocation.total_shards_per_node=6,意思是单个节点上最大能分配的分片是6个,导致此节点上无法分配额外的分片,副本分片缺失,集群变黄。

3.以下是官方给的reason分类

1)INDEX_CREATED:由于创建索引的API导致未分配。
2)CLUSTER_RECOVERED :由于完全集群恢复导致未分配。
3)INDEX_REOPENED :由于打开open或关闭close一个索引导致未分配。
4)DANGLING_INDEX_IMPORTED :由于导入dangling索引的结果导致未分配。
5)NEW_INDEX_RESTORED :由于恢复到新索引导致未分配。
6)EXISTING_INDEX_RESTORED :由于恢复到已关闭的索引导致未分配。
7)REPLICA_ADDED:由于显式添加副本分片导致未分配。
8)ALLOCATION_FAILED :由于分片分配失败导致未分配。
9)NODE_LEFT :由于承载该分片的节点离开集群导致未分配。
10)REINITIALIZED :由于当分片从开始移动到初始化时导致未分配(例如,使用影子shadow副本分片)。
11)REROUTE_CANCELLED :作为显式取消重新路由命令的结果取消分配。
12)REALLOCATED_REPLICA :确定更好的副本位置被标定使用,导致现有的副本分配被取消,出现未分配。

3、ES集群磁盘高低水位问题

1.es根据磁盘使用情况来决定是否继续分配shard,有两个重要的设置:

cluster.routing.allocation.disk.watermark.low:控制磁盘最小使用率。默认85%.说明es在磁盘使用率达到85%的时候将会停止分配新的shard。
cluster.routing.allocation.disk.watermark.high:控制磁盘的最大使用率。默认90%.说明在磁盘使用率达到90%的时候es将会relocate shard去其他的节点。

2.如果集群中所有data节点的磁盘使用率都达到90%,此时集群将拒绝写入,可以通过API动态调整高低水位值,例如低水位90%,高水位95%

curl -H ‘Content-Type:application/json‘ -XPUT ‘http://10.12.24.77:9202/_cluster/settings‘ -d‘{"transient" : {"cluster.routing.allocation.disk.watermark.low" : “90%","cluster.routing.allocation.disk.watermark.high" : “95%"}}‘

 

4、bulk、index 报错EsRejectedExcutionException[rejected execution(queue capacity 200) on.......

思路:找出拒绝bulk、index的data节点,默认bulk队列是200,调整成2000,然后查此节点磁盘、CPU,确认在报错时间点是否繁忙。

1.通过API查看下thread pool配置,默认index、bulk线程池大小与cpu核数保持一致,bulk、index queue_size默认是200,生产环境后期部署均给2000,发现是默认的200,可以调整到2000;

curl -XGET http://10.35.50.42:9201/_nodes/thread_pool?pretty

thread_pool.bulk.queue_size: 2000

2.通过cat thread_pool API查看各节点index、bulk拒绝数量统计,找出拒绝bulk、index请求的data节点;

curl -XGET http://10.35.50.42:9201/_cat/thread_pool?pretty

3.排查data节点在报错时间是否有IO、CPU繁忙的问题存在,如果集群中所有data节点均有拒绝,说明集群写入出现瓶颈,需要扩容或者更换性能更好的SSD盘。

5、缓解data节点IO wait高导致的CPU Load高的情况

1.当IO wait出现时,表明节点IO出现瓶颈,出现这种情况的同时,通常伴随着大量的数据写入,先判断如果是日志或对搜索实时性要求不是很高的场景,可以尝试修改索引settings

通常修改两处(可以动态修改),保证数据异步落盘,减少段合并频率,释放IO压力

"refresh_interval": "60s",
"translog": {
"flush_threshold_size": "500mb",
"sync_interval": "60s",
"durability": "async"
},

2.如果IO wait依然很高,可以考虑下掉副本,但这样索引数据的高可用就无法保证,需要看具体场景,同时和业务方确认;

3.给集群扩容data节点,或更换性能更高的SSD盘。

6、缓解JVM Heap使用率高的情况

1.先看JVM Heap已使用容量高会导致哪些问题:

1)写入性能查,index buffer缺少一定的内存空间用缓冲文档数据;

2)查询或搜索性能异常,缺少一定的数据缓存空间,导致查询超时或中断;

3)严重情况下出现内存溢出异常,节点宕机,java.lang.OutOfMemoryError: Java heap space

2.解决方法:

1)确认data节点的JVM配置大小,生产环境一般给30G;

2)关闭或删除过期的索引数据,释放出空间;

3)给集群扩容,并平衡分片。

 

7、当前查询加载数据会报”breaker.CircuitBreakingException: [parent] Data too large, data for [<http_request>] would be [1454565650/1.3gb], which is larger than the limit of...";

1.问题原因:fielddata缓存占用大量JVM Heap空间,其他索引无法分配更多的内存,所以当前查询加载数据会报错;

  通过API可以查看fielddata缓存占用的内存大小;GET /_stats/fielddata?pretty

2.解决方法:

1)通过设置indices.fielddata.cache.size值来修改单个索引占用缓存的大小,如果超出这个值,该数据将被逐出,设置方法有两种,一种是更新配置文件后重启生效,另一种是API动态修改

    indices.fielddata.cache.size: 20%       _cluster/settings { "persistent" : { "indices.breaker.fielddata.limit" : "20%" }}

2)清理fielddata缓存,清理后并确认;

curl  localhost:9200/index/_cache/clear?pretty&field_data=true

3)给当前集群扩容data节点。

 

以上是关于ES常见问题整理的主要内容,如果未能解决你的问题,请参考以下文章

IOS开发-OC学习-常用功能代码片段整理

VS2015 代码片段整理

小程序各种功能代码片段整理---持续更新

常用python日期日志获取内容循环的代码片段

30秒就能看懂的JavaScript 代码片段

《理解 ES6》阅读整理:函数(Functions)