1

ハングしているように見えるLinuxアプリケーション（ソースはありません）があります。2つのプロセス間のソケットはESTABLISHEDとして報告され、カーネルソケットバッファーにいくつかのデータがあります（ただし、wmem / rmemを介して構成された16Mにはほど遠いです）。ソケットの両端がsendto（）でスタックしているようです。

以下は、netstat/lsofとstraceを使用した調査です。

ホストA（10.152.20.28）

[root@hosta ~]# lsof -n -u df01 | grep 12959 | grep 12u
q         12959 df01   12u  IPv4            4398449                TCP 10.152.20.28:38521->10.152.20.29:gsigatekeeper (ESTABLISHED)

[root@hosta ~]# netstat -anp | grep 38521
tcp   268754  90712 10.152.20.28:38521          10.152.20.29:2119           ESTABLISHED 12959/q

[root@hosta ~]# strace -p 12959
Process 12959 attached - interrupt to quit
sendto(12, "sometext\0somecode\0More\0exJKsss"..., 542, 0, NULL, 0 <unfinished ...>
Process 12959 detached
[root@hosta~]#

ホストB（10.152.20.29）

[root@hostb ~]# netstat -anp | grep 38521
tcp    72858 110472 10.152.20.29:2119           10.152.20.28:38521          ESTABLISHED 25512/q

[root@hostb ~]# lsof -n -u df01 | grep 38521
q         25512 df01   14u  IPv4            6456715                 TCP 10.152.20.29:gsigatekeeper->10.152.20.28:38521 (ESTABLISHED)

[root@hostb ~]# strace -p 25512
Process 25512 attached - interrupt to quit
sendto(14, "\0\10\0\0\0Owner\0sym\0Type\0Ctpy\0Time\0Lo"..., 207, 0, NULL, 0 <unfinished ...>
Process 25512 detached
[root@hostb~]#

NICドライバーを最新かつ最高のものにアップグレードしました。システムはRHEL5.6x64（2.6.18-238.el5）を実行しており、RHEL 5.7および5.8のエラッタを確認しましたが、bnx2ドライバーまたはカーネルのバグについては言及されていません。

誰かがこれをさらにデバッグする方法について何かアイデアがありますか？

4

1 に答える 1

3

どちらの側も実際に読んでいますか？そうでない場合は、両側の受信バッファがいっぱいになり、（受信ウィンドウがいっぱいになるために）データが送信されず、両方の送信バッファがいっぱいになりsendto、ブロックが発生する可能性があります。SO_RCVBUF（アプリケーションがおよびSO_SNDBUFソケットオプションを設定している場合、wmem / rmemの設定にもかかわらず、これが発生する可能性があります。）

これをデバッグするには、両方のマシンのクロックを同期straceしてから、-e trace=networkand-ttオプションを使用して両方のアプリケーションを実行します。これにより、ログを比較して、アプリケーションが読み取っていないかどうかを確認できます。

ネットワークアナライザ（Wiresharkなど）を使用して、TCP受信ウィンドウが0でスタックしているかどうかを判断することもできます。

この場合、おそらく、小さなキャッシングプロキシを作成することでこれを回避できます。このプロキシは、両側から受信/送信し、その時点で送信できないものはすべてバッファリングします。

于 2011-09-15T11:38:36.347 に答える