hi
有的时候，es集群中某一个节点忽然 bulk queue full， 导致数据写入受阻，但是集群中的其他节点都是好的。从问题节点的日志上看，并没有发现明显的问题。
大家之前有遇到过这个问题吗? 一般都是如何排查的？
有的时候，es集群中某一个节点忽然 bulk queue full， 导致数据写入受阻，但是集群中的其他节点都是好的。从问题节点的日志上看，并没有发现明显的问题。
大家之前有遇到过这个问题吗? 一般都是如何排查的？
3 个回复
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已经验证）：
如果你的批量请求数目高于队列大小，将会出现RemoteTransportException异常。
JackGe
赞同来自:
shjdwxy
赞同来自:
（1）问题node上面某一个shard的流量忽然增加，导致这个节点bulk queue full。
这种是比较好监控和解决的。
（2）问题node的index流量并没有明显增加，但是heap的使用率明显增加，导致old gc频率增加，CPU使用率也增加。最终可能发生stop-the-world类型回收（node停止响应任何请求），甚至OOM。
这种比较难查原因。目前想到的方案就是 heap dump分析了。