问题分析：引入新elastic api导致的TIME_WAIT堆积

2019 年 11 月 2 日
筆記

之前使用github.com/olivere/elastic库遇到了一个TIME_WAIT堆积的问题，因为问题比较共性（引入新库、性能测试、TIME_WAIT原理），所以简单记录下，新同学可以关注下

发生背景：业务引入新elastic api
问题原因：http短连导致TIME_WAIT堆积
解决方法：合理设置/net/http连接池大小
思考反思：引入新库需谨慎，必须提前做功能和压力测试
相关扩展：TIME_WAIT状态有必要存在吗？
相关扩展：导致大量TIME_WAIT的常见原因和解决方案

发生背景：业务引入新elastic api

之前业务调用ES是走原生RESTful，用golang的net/http直接写客户端。由于这种方式要自己拼表达式，所以有同学就引入了github.com/olivere/elastic，对表达式封装了一层，让代码更加简单高效，示例：

但是模块发布后，陆续发现服务请求ES无响应，导致服务不可用，立即回滚先恢复。

问题原因：http短连导致TIME_WAIT堆积

明确ES本身没问题后，查看服务机器发现非常多调用ES的链接处在TIME_WAIT状态，命令实例：

[root@TENCENT64 ~]# netstat -n | grep "111.111.111.111:9200" | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  ESTABLISHED 2  TIME_WAIT 10503

太多的TIME_WAIT链接占满了端口65535的限制，导致新链接无法发起。

这里开始抠github.com/olivere/elastic 的源码，为啥已用了全局client还会导致大量TIME_WAIT：

github.com/olivere/elastic/client.go.png

可以看到，/olivere/elastic的ESClient最后也是调用了/net/http库，那核心就是看下他怎么管理http的client了：

可以得出初步结论：/olivere/elastic的ESClient使用了/net/http的默认全局http.DefaultClient，http.DefaultClient底层通讯Transport默认使用了DefaultTransport，而DefaultTransport初始化没设置 MaxIdleConnsPerHost，于是采了默认的DefaultMaxIdleConnsPerHost=2。即只支持2个tcp链接复用，并发数大的话很容易就超了，连接池拿不到链接的话就默认新创建短连了

解决方法：合理设置/net/http连接池大小

解决大量TIME_WAIT的方法有很多，针对这个case，这边需在初始化/olivere/elastic/client的时候，设置底层/net/http合理的连接池数量，如：

再压测观察链接数就恢复正常了：

[root@TENCENT64 ~]# netstat -n | grep "111.111.111.111:9200" | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  ESTABLISHED 100

连接池大小要设置多少算够？这里一个比较简单的实践：

单个连接QPS = 1s/平均延迟
最大连接数 = 业务QPS/单个连接QPS + 一点富余量

可以参考：https://partners-intl.aliyun.com/help/doc-detail/98726.htm

思考反思：引入新库需谨慎，必须提前做功能和压力测试

开发过程很多同学会引入各种各样的第3方库，帮忙团队提高研发效率，但引入前必须提前做好：

团队评估：关注使用普及度、业内反馈等
功能测试：关注边缘变量、异常处理等
压力测试：关注性能消耗，资源占用等