公司使用了 InfluxDB 作為監(jiān)控系統(tǒng)的存儲后端, 在一次上線后,發(fā)現(xiàn)與InfluxDB 使用的 8086 端口相關(guān)的 TCP 連接數(shù)竟然多大 6K+ ,有時候甚至會逼近 1w ,這個數(shù)量對于一個只是在內(nèi)部使用的監(jiān)控系統(tǒng)來說, 無論如何都是無法接受的, 于是開始一系列的排查過程. 本文記錄了這個問題的主要解決過程,算是對這一次殺 bug 過程的一個總結(jié).
問題描述
因為業(yè)務(wù)的需要, client 對 InfluxDB 做 query 時, 會經(jīng)過 server 的一個 proxy , 再由 proxy 發(fā)起到 Influxdb 的 query (http) 請求. 在我們的部署架構(gòu)中, proxy 與 InfluxDB 是部署在同一個 server 上的. 使用命令
netstat -apn | grep 8086
可以看到大量處于 TIME_WAIT狀態(tài)的 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
進行計數(shù), 會發(fā)現(xiàn)連接數(shù)會不斷增加, 經(jīng)過多次測試, 在公司環(huán)境中連接數(shù)至少都會達到 6k+. 這個問題必須要解決, 一方面是因為每條 tcp 連接都會占用內(nèi)存, 另一方面系統(tǒng)的動態(tài)端口數(shù)也是有限的.
很明顯這些連接幾乎都處在 TIME_WAIT 狀態(tài),所以在繼續(xù)往下走之前, 需要了解下 TIME_WAIT 這個關(guān)鍵字
TIME_WAIT
我們知道 一條 tcp 連接從開始到結(jié)束會經(jīng)歷多個狀態(tài), 換句話說, 可以把 一條 tcp 連接看成是一個 狀態(tài)機. 這個狀態(tài)圖如下:
可以看到, 凡是主動進行關(guān)閉 tcp 連接的一方, 都會經(jīng)過 TIME_WAIT 這個狀態(tài).接下來再經(jīng)過 2MSL 的時間后內(nèi)核再完全釋放相應(yīng)的文件描述符和端口. (順便提一下, MSL 是最大分段壽命, 是一個 TCP 分段可以存在于互聯(lián)網(wǎng)系統(tǒng)中的最大時間, 在 Linux 下可以用命令
cat /proc/sys/net/ipv4/tcp_fin_timeout
查看 MSL的數(shù)值)
到這個地方可以推斷出, 是 8086 端口(即 InfluxDB) 主動關(guān)閉了 tcp 連接, 導(dǎo)致擠壓了大量的處于 TIME_WAIT 狀態(tài)下的連接在等待內(nèi)核釋放. 于是自然而然得會想到, 能不能限制 InfluxDB 能打開的最大連接數(shù), 讓它盡可能復(fù)用每一條 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, 然后重啟數(shù)據(jù)庫.
然而并沒有什么卵用, 看來還是得繼續(xù)想辦法.
查看 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 字段被設(shè)置為 close .
因為已經(jīng)確定我們用 Go 編寫的用于對 InfluxDB 發(fā)起 http 請求的 proxy 已經(jīng)正確復(fù)用了 tcp 連接 , 所以就感覺問題應(yīng)該是處在了 InfluxDB 上, 所以接下來就開始翻開 InfluxDB 的源碼查看究竟.
文章中提到的 InfluxDB 版本為 1.2 , 處理 query 請求的代碼在services/httpd/handler.go 中, 函數(shù)簽名為
func (h *Handler) serveQuery(w http.ResponseWriter, r *http.Request, user meta.User)
在其中發(fā)現(xiàn)一句代碼
rw.Header().Add("Connection", "close")
看到這里感覺一切豁然開朗了, 確實是 Influxdb 主動關(guān)閉的連接, 并且通知 client (也就是文中提到的 proxy ) 在請求完成后也關(guān)閉連接.
為了驗證這一點, 我將上面那句代碼注釋掉后重新編譯 InfluxDB, 在 client 正確復(fù)用連接的情況下, 連接數(shù)確實可以保持在 10 以內(nèi).
現(xiàn)在問題就變成, InfluxDB 為何要這樣設(shè)計 ?
后續(xù)
在 Github 的一個 issue 上, 我向 InfluxDB 的官方反映了這個問題, 官方也注意到了, 可能在接下來的 1.3 版本會修復(fù)這個問題, 拭目以待.
--------- 更新 ------
Influxdb 之所以會強制關(guān)閉連接, 是因為 Go 對復(fù)用的連接使用
ResponseWriter.CloseNotify()
獲取通知的時候會有問題, 于是他們強制 client 在后續(xù)請求中重新建立連接而不是選擇復(fù)用.不過 InfluxDB 對連接的關(guān)閉通知做了一些另外的處理, 所以上面的那句代碼可以去掉.
