公司使用了 InfluxDB 作为监控系统的存储后端, 在一次上线后,发现与InfluxDB 使用的 8086 端口相关的 TCP 连接数竟然多大 6K+ ,有时候甚至会逼近 1w ,这个数量对于一个只是在内部使用的监控系统来说, 无论如何都是无法接受的, 于是开始一系列的排查过程. 本文记录了这个问题的主要解决过程,算是对这一次杀 bug 过程的一个总结.
问题描述
因为业务的需要, client 对 InfluxDB 做 query 时, 会经过 server 的一个 proxy , 再由 proxy 发起到 Influxdb 的 query (http) 请求. 在我们的部署架构中, proxy 与 InfluxDB 是部署在同一个 server 上的. 使用命令
netstat -apn | grep 8086
可以看到大量处于 TIME_WAIT状态的 tcp 连接
...
tcp6 0 0 127.0.0.1:8086 127.0.0.1:58874 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59454 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59084 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59023 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59602 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59027 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59383 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59053 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:58828 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:58741 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59229 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:58985 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59289 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59192 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59161 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59292 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59242 TIME_WAIT -
tcp6 0 0 127.0.0.1:8086 127.0.0.1:59430 TIME_WAIT -
...
使用命令
netstat -apn | grep 8086 | grep TIME_WAIT | wc -l
进行计数, 会发现连接数会不断增加, 经过多次测试, 在公司环境中连接数至少都会达到 6k+. 这个问题必须要解决, 一方面是因为每条 tcp 连接都会占用内存, 另一方面系统的动态端口数也是有限的.
很明显这些连接几乎都处在 TIME_WAIT 状态,所以在继续往下走之前, 需要了解下 TIME_WAIT 这个关键字
TIME_WAIT
我们知道 一条 tcp 连接从开始到结束会经历多个状态, 换句话说, 可以把 一条 tcp 连接看成是一个 状态机. 这个状态图如下:
可以看到, 凡是主动进行关闭 tcp 连接的一方, 都会经过 TIME_WAIT 这个状态.接下来再经过 2MSL 的时间后内核再完全释放相应的文件描述符和端口. (顺便提一下, MSL 是最大分段寿命, 是一个 TCP 分段可以存在于互联网系统中的最大时间, 在 Linux 下可以用命令
cat /proc/sys/net/ipv4/tcp_fin_timeout
查看 MSL的数值)
到这个地方可以推断出, 是 8086 端口(即 InfluxDB) 主动关闭了 tcp 连接, 导致挤压了大量的处于 TIME_WAIT 状态下的连接在等待内核释放. 于是自然而然得会想到, 能不能限制 InfluxDB 能打开的最大连接数, 让它尽可能复用每一条 tcp 连接?
果不其然, 在 InfluxDB 的配置文件中, 有这么一个配置项
# The maximum number of HTTP connections that may be open at once. connections that
# would exceed this limit are dropped. Setting this value to 0 disables the limit.
max-connection-limit = 0
我将其该为100, 然后重启数据库.
然而并没有什么卵用, 看来还是得继续想办法.
查看 InfluxDB 源码
接下来使用 curl 查看 Influxdb 返回的 http header
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Request-Id: 95e5b54b-6af3-11e7-8001-000000000000
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.3.0rc1
Date: Mon, 17 Jul 2017 13:26:48 GMT
Transfer-Encoding: chunked
可以看到 Connection 字段被设置为 close .
因为已经确定我们用 Go 编写的用于对 InfluxDB 发起 http 请求的 proxy 已经正确复用了 tcp 连接 , 所以就感觉问题应该是处在了 InfluxDB 上, 所以接下来就开始翻开 InfluxDB 的源码查看究竟.
文章中提到的 InfluxDB 版本为 1.2 , 处理 query 请求的代码在services/httpd/handler.go 中, 函数签名为
func (h *Handler) serveQuery(w http.ResponseWriter, r *http.Request, user meta.User)
在其中发现一句代码
rw.Header().Add("Connection", "close")
看到这里感觉一切豁然开朗了, 确实是 Influxdb 主动关闭的连接, 并且通知 client (也就是文中提到的 proxy ) 在请求完成后也关闭连接.
为了验证这一点, 我将上面那句代码注释掉后重新编译 InfluxDB, 在 client 正确复用连接的情况下, 连接数确实可以保持在 10 以内.
现在问题就变成, InfluxDB 为何要这样设计 ?
后续
在 Github 的一个 issue 上, 我向 InfluxDB 的官方反映了这个问题, 官方也注意到了, 可能在接下来的 1.3 版本会修复这个问题, 拭目以待.
--------- 更新 ------
Influxdb 之所以会强制关闭连接, 是因为 Go 对复用的连接使用
ResponseWriter.CloseNotify()
获取通知的时候会有问题, 于是他们强制 client 在后续请求中重新建立连接而不是选择复用.不过 InfluxDB 对连接的关闭通知做了一些另外的处理, 所以上面的那句代码可以去掉.
