您好,登錄后才能下訂單哦!
tcp socket文件句柄泄漏
今天發(fā)現(xiàn)有臺(tái)redis機(jī)器上出現(xiàn)socket個(gè)數(shù)告警,這是很奇怪的現(xiàn)象。因?yàn)橐慌_(tái)redis服務(wù)器上就部署了幾個(gè)redis實(shí)例,打開(kāi)的端口應(yīng)該是有限。
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存在泄漏,沒(méi)有被內(nèi)核回收。
3、追查真兇
上面信息說(shuō)明存在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找不到打開(kāi)的文件,。
這個(gè)顯示,是java進(jìn)程(pid=4684)出現(xiàn)了socket fd泄漏的狀況。
ps auxww | grep 4684
發(fā)現(xiàn)是redis機(jī)器上日志收集工具flume。
4、解決方案
今天發(fā)現(xiàn),重啟flume agent之后,仍然會(huì)出現(xiàn)這種大量的closed socket現(xiàn)象。
strace flume進(jìn)程,發(fā)現(xiàn)flume進(jìn)程已經(jīng)掛起了。
sudo strace -p 36111
Process 36111 attached - interrupt to quit
futex(0x2b80e2c2e9d0, FUTEX_WAIT, 36120, NULL
首先,我比較懷疑文件句柄不夠用,因?yàn)間oogle查找到的資料也提高了文件fd不夠而導(dǎo)致這種問(wèn)題。
在我的機(jī)器上,最大允許打開(kāi)的文件數(shù)為131072,文件fd個(gè)數(shù)還有近1/4沒(méi)有使用。
lsof | wc -l
10201
ulimit -a
ulimit -n
131072
這時(shí),同事提示我,還有其他大量機(jī)器也出現(xiàn)了這種問(wèn)題(flume已經(jīng)上線了3個(gè)月,之前都很正常)。
這是,我想起了還有flume的日志可以查看。而查看flume的日志,提示flume找不到broker 5。
納尼,不是kafka集群不是只有4個(gè)broker(節(jié)點(diǎn))。這時(shí)候才想起前幾天的郵件然來(lái)spark開(kāi)發(fā)的同事,對(duì)kakf集群進(jìn)行擴(kuò)容了。
而新的集群節(jié)點(diǎn)9092端口對(duì)這臺(tái)redis所在的機(jī)房沒(méi)有開(kāi)放訪問(wèn)權(quán)限。
[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、問(wèn)題重現(xiàn)
在lsof: can’t identify protocol這篇文章中,用python代碼重現(xiàn)了這種狀況。
:)
在解決問(wèn)題時(shí),google查找是一種比較快捷的方式。而有時(shí)候,google出來(lái)的結(jié)果反而會(huì)影響排查問(wèn)題的方向。
在我看到google的搜索結(jié)果之后,第一感覺(jué)是因?yàn)椴僮飨到y(tǒng)的max open files參數(shù)太小導(dǎo)致。在發(fā)現(xiàn)不是這個(gè)原因之后。我的思路仍然停留在內(nèi)核參數(shù)是否配置合理的思路上。知道其他的機(jī)器上部署的flume出現(xiàn)了同種狀況是,我才意識(shí)到是flume本身出了問(wèn)題,才去strace flume進(jìn)程的狀態(tài)和查看flume的日志。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。