10

私たちのアプリケーションは、JavaのTCP/IPソケットを介して非常に高速にデータを読み取っています。読み取りの準備ができていることを示すために、ノンブロッキングソケットとセレクターを備えたNIOライブラリを使用しています。平均して、読み取られたデータの読み取りと処理の全体的な処理時間は1ミリ秒未満です。ただし、10〜20ミリ秒のスパイクが頻繁に見られます。（Linuxで実行）。

tcpdumpを使用すると、tcpdumpが2つの個別のメッセージを読み取ったときの時間差を確認し、それをアプリケーションの時間と比較できます。tcpdumpには遅延がないように見えますが、アプリケーションは20ミリ秒を表示できます。

GCログには実質的にフルGCが表示されないため、これはGCではないと確信しています。JDK6では（私が理解しているように）デフォルトのGCは並列であるため、アプリケーションスレッドを一時停止しないでください（フルGCを実行しない限り）。 。

Selector.select(0)TCP層では、データを既に読み取ることができる（そしてtcpdumpがデータを読み取っている）ため、Javaのメソッドが読み取りの準備を返すのに多少の遅延があるように見えます。

追加情報：ピーク負荷では、メッセージあたり平均約6,000 x 150バイト、つまり1秒あたり約900MBを処理しています。

4

4 に答える 4

4

edenコレクションには引き続きSTWの一時停止が発生するため、割り当て動作とヒープサイズ/ライブセットのサイズによっては、20ミリ秒が完全に正常である可能性があります。

于 2011-03-14T21:27:52.730 に答える
3

JavaコードはRTLinuxで実行されていますか、それともハードリアルタイムスケジューリング機能を備えた他のディストリビューションですか？そうでない場合、処理時間の10〜20ミリ秒のジッターは完全に合理的であり、予想されます。

于 2011-03-14T18:23:15.857 に答える
2

私が取り組んでいるJavaサービスでも同じ問題が発生しました。クライアントから同じリクエストを繰り返し送信すると、サーバーはストリーム内の同じ場所で25〜35ミリ秒間ブロックします。ソケットでNagleのアルゴリズムをオフにすると、これが修正されました。これは、ソケットでsetTcpNoDelay（true）を呼び出すことで実現できます。これにより、ACKが個別のパケットとして送信されるようになるため、ネットワークの輻輳が増加する可能性があります。Nagleのアルゴリズムの詳細については、 http：//en.wikipedia.org/wiki/Nagle%27s_algorithmを参照してください。

于 2011-06-21T20:54:21.627 に答える
1

tcpdumpに関するよくある質問から：

パケットのタイムスタンプはいつですか？タイムスタンプはどの程度正確ですか？

tcpdumpとlibpcapが実行されるほとんどのOSでは、パケットは、ネットワークインターフェイスのデバイスドライバーまたはネットワークスタックが処理するプロセスの一部としてタイムスタンプが付けられます。これは、パケットがネットワークインターフェイスに到着した瞬間にタイムスタンプが付けられないことを意味します。パケットがネットワークインターフェイスに到着した後、割り込みが配信されるか、ネットワークインターフェイスがポーリングされるまで、遅延が発生します（つまり、ネットワークインターフェイスがホストにすぐに割り込みをかけない場合があります。ネットワークの場合、ドライバはインターフェイスをポーリングするように設定されている可能性があります。割り込みの数を減らし、割り込みごとにより多くのパケットを処理するために、トラフィックは大量であり、割り込みの処理が開始されてからタイムスタンプが生成されるまでにさらに遅延が発生します。

つまり、タイムスタンプは特権カーネルレイヤーで作成され、失われた20ミリ秒は、オーバーヘッドをユーザースペースに戻し、JavaとJVMネットワークセレクターロジックにコンテキストスイッチすることです。システム全体をさらに分析しなければ、原因を積極的に選択することはできないと思います。

于 2011-03-14T18:58:13.087 に答える