-
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;
thread_pool.bulk.queue_size: 2000
2.通过cat thread_pool API查看各节点index、bulk拒绝数量统计,找出拒绝bulk、index请求的data节点;
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)给集群扩容,并平衡分片。
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节点。
-
相关阅读:
[HAOI2012]高速公路(BZOJ2752)
[SHOI2008]堵塞的交通traffic(BZOJ1018)
AHOI2009 行星序列Seq (BZOJ1798)
java注解问题
回调方法举例
log4j将日志文件保存到项目中
ehCache+springMVC的简单实用
MyBatis排序时使用order by 动态参数时需要注意,用$而不是#
mybatis配置log4j
mybatis ---- 分页 (拦截器)
-
原文地址:https://www.cnblogs.com/lwhctv/p/12327627.html
Copyright © 2020-2023
润新知