0

私たちはいくつかの Java ストレス ランを行っています (ネットワーク IO を含む)。最初はすべて問題なく、システムは非常に高速に応答します (テストでの平均遅延は 2 ミリ秒)。しかし、数時間後に同じテストをやり直すと、パフォーマンスが低下することがわかります (20 ～ 60 ミリ秒)。同じ Jar ファイル、同じ JVM、およびストレスが実行されている同じ LAN です。この動作の理由がわかりません。

LAN は 1GBPS であり、ストレス要件のために、すべてを使用しているとは限りません。

だから私のQN：

  1. LAN 内のいくつかのスイッチが原因でしょうか?
  2. しばらくするとマシンの速度が低下しますか (マシンは再起動されます.. ストレスが発生する前に、約 6 か月前にさかのぼります。それらは RHEL5、XEON 64 ビット クアッド コアです)
  3. このような問題をデバッグする一般的な方法は何ですか?

何か助けてください。

-- ラビ

4

2 に答える 2

0

いくつかの質問...

管理下にある環境はどれくらいですか? また、実行ごとに一貫性を確保するための対策を講じていますか? たとえば、ネットワークを他のシステムと共有していますか? 使用しているマシンはストレス テストだけに使用されていますか?

私がこれを見る方法は、あなたのマシンとコードが何をしようとしているのかについての詳細を収集し始めることです. つまり、perfmon (windows) sar (unix) を使用して OS とハードウェアが何をしているかを調べ、プロファイラーを接続してコードが同じことをしていることを確認し、コードの観点からボトルネックが発生している場所を特定するのに役立ちます。 .

それほど詳しくはありませんが、始めるのに役立つことを願っています。

于 2010-02-22T05:22:52.563 に答える
0

一般的な方法は「すべてを測定する」です。これは、特に次のことを意味する場合があります。

  1. すべてのサーバーの時刻が同じであることを確認します (ntp などを使用します)。
  2. リクエストの生成にかかった時間を測定します (リクエスト ジェネレーターにバグがある場合はどうなりますか?)。
  3. リクエストがいつクライアント マシンを離れたか、または少なくとも I/O の実行にかかった時間を測定します。多くのリクエストに必要な平均時間を知るだけで十分な場合があります。
  4. リクエストがいつ到着したかを測定します。
  5. 応答を生成するのにかかった時間を測定します。
  6. 応答を送信するのにかかった時間を測定します。

これは（あなたが信じている）クリティカルチェーンであるため、おそらく5番目の要素から始めることができます. ただし、できる限りログを記録することをお勧めします。自分で言ったことによると、さまざまな結果が得られるまでに数日かかります。

コードを変更したくない場合は、介入せずにデータを盗聴できるケースを探します (たとえば、web.xml でサーブレット フィルターを定義します)。

于 2010-02-22T14:34:56.933 に答える