大家好，又见面了，我是你们的朋友全栈君。
现象：往es7集群中推数时，发生如下情况
- 接口出现很多400
- 发现集群中某台机器cpu被怼爆
- 发生fullGC
产生400报错的原因是es7做了熔断优化，当jvm内存使用超过阈值，为了避免丑陋的oom，会直接限流并抛出EsRejectedExecutionException。
我们强硬的关掉了这个配置，因为我们的推数有失败重试。
产生fullGC是因为一个bulk批处理的数据量太大，我们一个文档1.5M，800个文档作为一批，两个线程并行推，jvm内存30G，所以es服务器很快就开始进行fullGC。
所以我们立刻将bulk的数量调整为50，并改为单线程推送，终于没有出现fullGC。
bulk会把将要处理的数据载入内存中，所以数据量是有限制的，最佳的数据量不是一个确定的数值，它取决于你的硬件，你的文档大小以及复杂性，你的索引以及搜索的负载。 一般建议是1000-5000个文档，如果你的文档很大，可以适当减少队列，大小建议是5-15MB，默认不能超过100M，可以在es的配置文件（即$ES_HOME下的config下的elasticsearch.yml）中。
产生单台机cpu爆炸的原因
- primary shard主副分片分布不均。
- master node既是master node又是data node，master node既要做数据检索，也要做集群的负载均衡转发器，导致每个集群的master node的CPU都很高，因此每次告警首先都是master node。
如果是情况1，则需要移动主分片。
例如移动node-1的分片0到node-4。
代码语言：javascript复制curl -XPOST 'http://localhost:9200/_cluster/reroute' -d '{
"commands":[{
"move":{
"index":"indexName",
"shard":0,
"from_node":"node-1",
"to_node":"node-4"
}}]}'优点：操作简单，恢复时间短；不必修改master node的配置，master node长期负载后高
缺点：索引大，移动时有很高的IO，索引容易损坏，需要做备份，不能解决master node既是数据节点又是负载均衡转发器的问题。
注意：分片和副本无法移动到同一个节点
若为情况2，则需重建索引，从另外一个集群导入。
删除原来的索引，重新建立索引；利用elasticsearch dump等工具从另一个集群中把数据导入到新的索引中。
优点：可以重新配置master node和data node，主从负载均匀。
缺点：费时间，容易数据丢失，需要验证数据的一致性。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/142716.html原文链接：https://javaforall.cn
