tcp socket文件句柄泄漏

成都創(chuàng)新互聯(lián)成立以來不斷整合自身及行業(yè)資源、不斷突破觀念以使企業(yè)策略得到完善和成熟，建立了一套“以技術為基點，以客戶需求中心、市場為導向”的快速反應體系。對公司的主營項目，如中高端企業(yè)網(wǎng)站企劃 / 設計、行業(yè) / 企業(yè)門戶設計推廣、行業(yè)門戶平臺運營、app開發(fā)定制、成都手機網(wǎng)站制作、微信網(wǎng)站制作、軟件開發(fā)、服務器托管等實行標準化操作，讓客戶可以直觀的預知到從成都創(chuàng)新互聯(lián)可以獲得的服務效果。

今天發(fā)現(xiàn)有臺redis機器上出現(xiàn)socket個數(shù)告警，這是很奇怪的現(xiàn)象。因為一臺redis服務器上就部署了幾個redis實例，打開的端口應該是有限。

1、netstat顯示的tcp連接數(shù)正常

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'`

TIME_WAIT        221
ESTABLISHED      103

netstat  -nat |wc -l
368

建立的tcp連接數(shù)并不是很多。

ss -s顯示大量的closed連接

ss -s

Total: 158211 (kernel 158355)
TCP:   157740 (estab 103, closed 157624, orphaned 0, synrecv 0, timewait 173/0), ports 203

Transport Total     IP        IPv6
158355    -         -        
RAW       0         0         0        
UDP       9         6         3        
TCP       116       80        36       
INET      125       86        39       
FRAG      0         0         0        
closed 157624

而我的系統(tǒng)監(jiān)控取值方法是:

cat /proc/net/sockstat | grep sockets | awk '{print $3}'
158391

cat /proc/net/sockstat
sockets: used 158400
TCP: inuse 89 orphan 2 tw 197 alloc 157760 mem 16
UDP: inuse 6 mem 0
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

很多socket處于alloc狀態(tài)，已經(jīng)分配sk_buffer,而且處于closed。
redis的file discriptes存在泄漏，沒有被內(nèi)核回收。

3、追查真兇
上面信息說明存在socket fd泄漏，那么用lsof命令檢查系統(tǒng)sock的文件句柄。

lsof | grep sock
java        4684      apps *280u     sock                0,6       0t0 675441359 can't identify protocol
java        4684      apps *281u     sock                0,6       0t0 675441393 can't identify protocol
java        4684      apps *282u     sock                0,6       0t0 675441405 can't identify protocol
java        4684      apps *283u     sock                0,6       0t0 675441523 can't identify protocol
java        4684      apps *284u     sock                0,6       0t0 675441532 can't identify protocol
java        4684      apps *285u     sock                0,6       0t0 675441566 can't identify protocol

可以發(fā)現(xiàn)，Name列的值為“an’t identify protocol”，socket找不到打開的文件，。

這個顯示，是java進程（pid=4684）出現(xiàn)了socket fd泄漏的狀況。

ps auxww | grep 4684

發(fā)現(xiàn)是redis機器上日志收集工具flume。

4、解決方案

今天發(fā)現(xiàn)，重啟flume agent之后，仍然會出現(xiàn)這種大量的closed socket現(xiàn)象。
strace flume進程，發(fā)現(xiàn)flume進程已經(jīng)掛起了。

sudo strace -p 36111
Process 36111 attached - interrupt to quit
futex(0x2b80e2c2e9d0, FUTEX_WAIT, 36120, NULL
首先，我比較懷疑文件句柄不夠用，因為google查找到的資料也提高了文件fd不夠而導致這種問題。
在我的機器上，最大允許打開的文件數(shù)為131072，文件fd個數(shù)還有近1/4沒有使用。

lsof | wc -l 
10201

ulimit -a 
ulimit  -n
131072

這時，同事提示我，還有其他大量機器也出現(xiàn)了這種問題（flume已經(jīng)上線了3個月，之前都很正常）。
這是，我想起了還有flume的日志可以查看。而查看flume的日志，提示flume找不到broker 5。
納尼，不是kafka集群不是只有4個broker（節(jié)點）。這時候才想起前幾天的郵件然來spark開發(fā)的同事，對kakf集群進行擴容了。
而新的集群節(jié)點9092端口對這臺redis所在的機房沒有開放訪問權限。

[SinkRunner-PollingRunner-DefaultSinkProcessor] (kafka.utils.Logging$class.warn:89) - Failed to send producer request with correlation id 63687539 to broker 5 with data for partitions [titan,4]

5、問題重現(xiàn)
在lsof: can’t identify protocol這篇文章中，用python代碼重現(xiàn)了這種狀況。

：）

在解決問題時，google查找是一種比較快捷的方式。而有時候，google出來的結果反而會影響排查問題的方向。
在我看到google的搜索結果之后，第一感覺是因為操作系統(tǒng)的max open files參數(shù)太小導致。在發(fā)現(xiàn)不是這個原因之后。我的思路仍然停留在內(nèi)核參數(shù)是否配置合理的思路上。知道其他的機器上部署的flume出現(xiàn)了同種狀況是，我才意識到是flume本身出了問題，才去strace flume進程的狀態(tài)和查看flume的日志。

新聞標題：tcpsocket文件句柄泄漏
當前鏈接：http://www.chinadenli.net/article46/gpedeg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、電子商務、網(wǎng)站改版、網(wǎng)站排名、企業(yè)網(wǎng)站制作、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)