5.4.1 中search线程池核心线程数没有做限制的原因

Elasticsearch | 作者 code4j | 发布于2019年09月04日 | 阅读数:109

前两天我遇到一个节点GC问题,最终经过排查发现是因为本身及其资源比较饱和的情况下,运维同学配置误操作将search的核心线程数写成了128,导致当出现大查询的时候search线程关联的返回结果比较多导致的(索引比较多,分片7800个)。
看了下源码,对于index线程池,即使自定义了线程池核心线程数(thread_pool.index.size),最大不会超过32, 而search 线程池来说,核心线程数如果不设置,最大是核数的1.5倍,但是如果是配置的话最大可以是 Integer.MAX_VALUE.  如果thread_pool.search.size被用户误操作配置了一个很大的数值,引擎是不会做限制的。

企业微信截图_92bdb635-d54d-4b3e-b928-ddc58e5ff683.png


最大线程数计算代码,max可以达到Integer最大值。


thread.png


fiex线程池创建,可以看到最大和核心线程数是一样的。

所以我觉得search难道不应该加一个保护措施嘛,手误就蛋疼了
 
已邀请:

laoyang360 - [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

code4j大神看得真仔细。
这应该是低版本的bug,高版本已经修复:https://github.com/elastic/ela ... fca62
 private int applyHardSizeLimit(String name, int requestedSize) {
int availableProcessors = EsExecutors.boundedNumberOfProcessors(settings);
if (name.equals(Names.BULK) || name.equals(Names.INDEX)) {
// We use a hard max size for the indexing pools, because if too many threads enter Lucene's IndexWriter, it means
// too many segments written, too frequently, too much merging, etc:

// TODO: I would love to be loud here (throw an exception if you ask for a too-big size), but I think this is dangerous
// because on upgrade this setting could be in cluster state and hard for the user to correct?
return Math.min(requestedSize, availableProcessors);
} else {
return requestedSize;
}
}

要回复问题请先登录注册