TCPソケット、ファイルハンドルリーク
今日、これは非常に奇妙な現象である、ソケット警告の数は、機械テーブルのRedisの上に表示されていることがわかりました。そのため、いくつかの例の展開上の1つのRedis Redisのサーバー上で、開いているポートを制限する必要があります。
1、TCP接続の通常の表示は、netstat
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数は多くはありません。
SSは、接続された閉じた多数の表示-s
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そして、私の値は、システムの監視方法は次のとおりです。
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 0alloc状態の多くのソケットは、sk_bufferを割り当てられており、中には閉じました。
ファイルdiscriptesの漏洩をRedisの、カーネルが回収されません。
図3は、殺人ダウントラックは
、システムの靴下ファイルハンドルを確認するためにコマンドlsofを使用し、説明上記ソケットFDリークの情報が存在します。
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見つけることができる、名前の欄には、ソケットが開いているファイルを見つけることができませんでした「an'tプロトコルを識別」です。
この表示は、Javaプロセス（PID = 4684）は、ソケットがリーク状況をfdが登場しています。
PS auxww | grepの4684
水路ログ収集ツールは、Redisのマシン上で発見されました。
4.ソリューション
今日は、再起動水路エージェント後に発見された、まだこの現象の閉じたソケットが多数存在します。
straceの水路プロセスは、私たちは水路プロセスがハングしていました。
36111はsudo -p straceの
添付プロセス36111 -割り込みの終了
のfutex（0x2b80e2c2e9d0、FUTEX_WAIT、36120、NULL
情報を見つけるためにGoogleはまた、ファイルが不足の原因にこの問題をfdが増加するため、すべての最初に、私はより多くの懐疑的なファイルハンドルだが、十分ではありません。
で私のマシン上で、開いているファイルの最大許容数は131072で、4分の1近くFDのファイル番号が使用されていません。
lsof | wc -l
10201
ulimit -a
ulimit -n
131072この時、同僚が私を促し、他のマシンの多くは、この問題に登場してきたが（水路は3ヶ月間のオンラインされている、前に正常である）されています。
これは私が水路を表示することができ、ログがあると思い、あります。そして、水路がブローカー5を見つけることができません示唆、ログ水路を表示します。
ナニ、カフカないクラスタだけでなく、4ブローカ（ノード）。それを覚えていると、その数日前にして、同僚のスパーク開発への電子メール、kakfクラスタの展開。
新しいクラスタノード9092ポートは、部屋がオープンアクセスではないこの段階のRedis。
[SinkRunner-PollingRunner-DefaultSinkProcessor（kafka.utils.Logging $のclass.warn：89） - パーティションのデータと5を仲介する相関ID 63687539と生産要求の送信に失敗しました[タイタン、4]
5、問題を再現するため
のlsofで：状況を再現するためのプロトコルにこの記事、使用するPythonコードを識別することはできません。
:)
問題を解決するには、検索グーグル、より効率的な方法です。そして、時には、それは問題の調査の方向に影響する結果を出しグーグル。
私はGoogleの検索結果を見た後は、オペレーティング・システムの最大オープン・ファイルのパラメータが小さすぎるリードがあるので、最初の感があります。発見後の理由ではありません。私の思考はまだカーネル構成パラメーターで立ち往生している合理的な考え方です。状況の同じ種類の他のマシン上で展開知っているが、フルームが、私は、プロセスのstraceの水路状態を行く前に、水路自体が問題で実現し、ログ水路を見ることで現われました。