是时候用 ES 拯救发际线啦

es 分片均匀,但只有其中一个节点负载特别高,bulk也堆积非常多

Elasticsearch | 作者 knight | 发布于2018年10月16日 | 阅读数:5633

业务日志分布在其中的6个data节点中,每个节点只起一个分片,从磁盘空间使用看出是均匀写入到6个节点中,如图中磁盘空间为2.7T/2.8T的那6个节点。
 
但是发现只有其中一台的负载特别高,查看thead_pool也只有负载高的那台有堆积,其他是基本不用的状态!!!求解!!!
3.png 2.png
已邀请:

kennywu76 - Wood

赞同来自:

查看问题结点的ES服务器日志,看有无异常。 机器的内核日志也看一下,以防硬件(磁盘)故障。

paLog

赞同来自:

是一直这样还是偶尔出现这种情况,有没有可能是有单条太长的业务日志消息过来写入的时候阻塞了其他线程,或者重启试一下

laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

看看这个节点的硬件配置(内存、cpu)是不是和其他几台不一致,可能是这个原因导致负载高。

zqc0512 - andy zhou

赞同来自:

多半是所有主分片搞到这个节点上面去了……
移动下数据。

yanlei

赞同来自:

我们的集群也一直存在这个问题,你找到原因了吗?

God_lockin

赞同来自:

这个节点是不是master节点?
是不是你所有的client的都直连的是这个节点?
你有没有在这个节点上单独部署或者运行什么其他的服务?
 
可以从这些方面去考虑一下

fanmo3yuan

赞同来自:

1. 可以先看看这个节点的role和其它有没有区别,确认是否是master节点引起的
2. 在看看这个节点上的shard和其它节点上的shard分布是否相同,确认是否是某些热shard引起的,可以试着reroute 相关到其它节点验证
3. 看看机器,硬件的信息,确认是否是机器问题

puyunjiafly

赞同来自:

1.这一个索引是平均分配的,那其他索引呢?es 分片默认分配算法好像是直接按节点node数平均分配的不看大小,是不是有其他大分片分配到了这台机器。
2.还有就是bulk的routing  是不是录入数据大量倾斜导致绝大数数据是只往这一个分片录入,如指定routing=北京(地域) bulk中地域数据百分之90都是北京,可以从分片对应文档数量查看数据是否倾斜严重,然后想修改策略。
3.查看该机器,看是否是硬件或配置导致的原因。
 
找到原因可以分享下原因。

要回复问题请先登录注册