前两天我遇到一个节点GC问题,最终经过排查发现是因为本身及其资源比较饱和的情况下,运维同学配置误操作将search的核心线程数写成了128,导致当出现大查询的时候search线程关联的返回结果比较多导致的(索引比较多,分片7800个)。
看了下源码,对于index线程池,即使自定义了线程池核心线程数(thread_pool.index.size),最大不会超过32, 而search 线程池来说,核心线程数如果不设置,最大是核数的1.5倍,但是如果是配置的话最大可以是 Integer.MAX_VALUE. 如果thread_pool.search.size被用户误操作配置了一个很大的数值,引擎是不会做限制的。
最大线程数计算代码,max可以达到Integer最大值。
fiex线程池创建,可以看到最大和核心线程数是一样的。
所以我觉得search难道不应该加一个保护措施嘛,手误就蛋疼了
看了下源码,对于index线程池,即使自定义了线程池核心线程数(thread_pool.index.size),最大不会超过32, 而search 线程池来说,核心线程数如果不设置,最大是核数的1.5倍,但是如果是配置的话最大可以是 Integer.MAX_VALUE. 如果thread_pool.search.size被用户误操作配置了一个很大的数值,引擎是不会做限制的。
最大线程数计算代码,max可以达到Integer最大值。
fiex线程池创建,可以看到最大和核心线程数是一样的。
所以我觉得search难道不应该加一个保护措施嘛,手误就蛋疼了
1 个回复
laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net
赞同来自:
这应该是低版本的bug,高版本已经修复:https://github.com/elastic/ela ... fca62