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 [] 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节点。