Hello,World

某个节点线程池爆了,导致整个服务响应很慢

Elasticsearch | 作者 2bqianbi | 发布于2018年05月28日 | 阅读数:2699

如标题:
我们有个节点的search线程池爆了,导致整个搜索服务响应很慢,不知道大家有没碰到过这种情况:有个疑问是:
1,这种情况下,集群不会把这台机器给剔除掉么?或者有什么自动恢复机制么?
2,对应用层面,能做哪些优化么?
已邀请:

code4j - coder github: https://github.com/rpgmakervx

赞同来自: rockybean laoyang360 cccthought

 
顺着楼上大牛的思路,现有业务场景下,评估一下你的线程池模型是否合理
 
举个例子:
一个节点假设配置search线程池为16,队列长度为1000, 一个线程处理一个搜索请求处理耗时是20ms,那么一个线程一秒可以处理50个请求。 那么理论上16个线程一秒可以处理900个请求,1000+16的线程队列大小是能够容纳qps为900的业务的(当然这是理论上,没有考虑的线程上下文切换,网络原因,内存GC导致stw等等,所以实际值肯定比这个低)。
 
线程数我觉得就核数两倍好了,最多2.5倍,太多了cpu上来反而影响效率(这个看实际情况,假设写少读多可以适当平衡这些线程数)
 
我认为可以参照如下公式得出
 
queueSize < thread*(1s*1000/cost)
 
然后我提出我的思考方式,我觉得你应该优化一下你的查询。是不是存在耗时很高的查询请求。
如上面分析的,假设你一个查询耗时200ms,那么你16个线程的处理能力瞬间变成 < 90 req/s,如果还有耗时更高的耗时呢,
 
可以先优化线程模型,顺便捕捉下慢查询。

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

赞同来自:

1不挂的话应该不会走剔除
2线程池和队列大小做下配置优化。

要回复问题请先登录注册