0

リッスン UDP ソケットとアクティブな SCTP ソケットの 2 種類のソケットを使用するアプリケーションがあります。

特定の時点で、同じマシン上で IO アクティビティ (「dd、tar、...」など) が高いスクリプトが実行されています。ほとんどの場合、これらの IO 負荷の高いアプリケーションを実行すると、次の問題が発生するようです。

  • UDP ソケットが閉じます
  • SCTP ソケットはまだ有効で、/proc/net/sctp/assocs で確認できますが、このソケットからのトラフィックは受信されません (アプリケーションを再起動するまで)。

これらの I/O 操作が、ネットワーク ベースのアプリケーションにそのような影響を与えるのはなぜですか?
これらの問題を回避するためのカーネル構成はありますか?
UDP でいくつかのパケットが失われ、SCTP ソケットでいくつかの再試行が行われると予想していましたが、この動作はそうではありませんでした。

アプリケーションは、64 ビットの 4 クアッド コア CPU と RHEL OS を搭載したサーバーで実行されています。

# uname -a
Linux server1 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
4

3 に答える 3

1

UDP ソケットが閉じると言うとき、正確にはどういう意味ですか? あなたが試しsendてみて、それは失敗しますか？

SCTP の場合、これらの I/O 操作の実行時に Wireshark または pcap トレースを収集できますか (できれば、ピアで Wireshark を実行します)。私の推測では (コードを見ずに知識に基づいた推測を行います)、これらの I/O 操作が発生すると、プロセスは CPU 時間に飢えます。もう一方の端SCTP Heartbeat messagesは、応答がない送信先に送信します。SACKSまたは、データが流れていた場合、エンドの SCTP スタックによってまだ処理されていないため、ピア エンドはデータを受信して​​いません。

したがって、ピアはアソシエーションを内部的に中止し、データの送信を停止します (すべてのパスがダウンしているため、ABORT は送信されません。このような場合、SCTP スタックはアソシエーションが有効であると見なします)。Heartbeat timeout, RTO timeout,SACK timeout, maximum Path retransmission & max Association retransmissionピア エンドでの値を確認してください。私はカーネル SCTP を扱ったことはありませんが、sysctl はそれらの値を提供できるはずです。

いずれにせよ、この問題を観察したときに pcap トレースを収集すると、何が問題なのかについてより良い洞察が得られます。お役に立てば幸いです。

于 2010-06-27T13:25:10.703 に答える
0

ここに私が調べたいことがいくつかあります：

スクリプトが実行されていないとき、UDP ソケットには何がロードされていますか? 連続ですか、それともバーストですか？スクリプトが実行されていないときに、ソケットが自発的に閉じることはありますか? ソケットから読み取られているデータに何が起こっていますか? ソケットから生成された (未処理または処理済みの) データのうち、ディスクに書き込まれているデータの量は? CPU、ネットワーク、およびディスク IO の使用率を監視して、それらのいずれかが飽和しているかどうかを確認できますか? IO 操作を実行するスクリプトを低い優先度で実行できますか? 逆に、UDP ソケットを実行するプロセスを高い優先度で実行できますか?

于 2010-06-27T14:09:28.440 に答える
0

多くの人がチェックしないことの 1 つは、送信時の戻り値であり、EINTRonrecvのようなエラー状態をチェックしません。重い IO 負荷が原因でsendや の一部recvが中断され、アプリがエラーをハード エラーとして認識し、エラーが一時的なものであることに気付かずにソケットを閉じている可能性があります。

この種の現象が発生するのを見てきました。ログ レベルを上げて、アプリが予期せず終了を呼び出しているかどうかを確認することで、確実に確認する必要があります。

于 2010-06-27T14:23:48.637 に答える