好的想法是十分钱一打,真正无价的是能够实现这些想法的人。

es集群中某一个节点忽然 bulk queue full

Elasticsearch | 作者 shjdwxy | 发布于2018年04月04日 | 阅读数:5613

hi
有的时候,es集群中某一个节点忽然 bulk queue full, 导致数据写入受阻,但是集群中的其他节点都是好的。从问题节点的日志上看,并没有发现明显的问题。
 
大家之前有遇到过这个问题吗? 一般都是如何排查的?
 
已邀请:

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

赞同来自: luxx

除了楼上思路,排查下线程池和队列大小是否设置合理,参考:
线程池大小配置

尽量不要动这个配置,如果要动,建议改为: 
int(( 核心数 * 3 )/ 2 )+ 1 。 
同时满足:不允许bulk和’indexing’线程池的大小大于CPU内核数。

举例:24核处理器,检索服务器是24核,所以:线程池的大小=(24*3)/2+1=37, 
同时要满足cpu核数为24。37和24取最小值,应该选择24。

默认的队列大小是1000, 
现在的问题是:并发请求数据超过了队列最大的大小,导致出错。

可能的解决方案: 
1)、增加队列大小;(太大了,可能会导致内存溢出) 
2)、增加节点数和副本数。

队列大小: 
在elasticsearch.yml中新增如下配置(5.X已经验证):
## Threadpool Settings ##

# Search pool
thread_pool.search.size: 24
thread_pool.search.queue_size: 2000

# Bulk pool
thread_pool.bulk.size: 24
thread_pool.bulk.queue_size: 1000

# Index pool
thread_pool.index.size: 24
thread_pool.index.queue_size: 1000


如果你的批量请求数目高于队列大小,将会出现RemoteTransportException异常。

JackGe

赞同来自:

集群中一个es datanode bulk队列满,先排查集群中索引shard是否分配均衡,以及这个节点上有实时数据写入的shard个数,再观察这个节点的ioutil情况,是否是因为磁盘原因。如果索引指定的routing字段,还需要排查是否因为routing字段不均匀,某个字段值特别多导致某个shard特别大。

shjdwxy

赞同来自:

目前排查下来出现这个问题主要有下面两种诱因:
(1)问题node上面某一个shard的流量忽然增加,导致这个节点bulk queue full。
这种是比较好监控和解决的。
(2)问题node的index流量并没有明显增加,但是heap的使用率明显增加,导致old gc频率增加,CPU使用率也增加。最终可能发生stop-the-world类型回收(node停止响应任何请求),甚至OOM。
这种比较难查原因。目前想到的方案就是 heap dump分析了。

要回复问题请先登录注册