0

実行中のバッチ ジョブのパフォーマンスを監視するよう依頼されました。バッチ ジョブは Jeus アプリケーション サーバー上で実行され、48 コアの HP UX サーバー上で実行されます。問題のバッチ ジョブには、約 1500 のスレッドがあります。最大で発生した例外は NumberFormatException です。ただし、バッチ ジョブは終了せず、引き続き実行されます。

HPJmeter を使用して監視しているときに、何千もの例外がスローされていることに気付きました。NumberFormat はよく使用されるものの 1 つにすぎませんが、他にもたくさんあります。次の質問があります。

  • これは設計/コーディングが悪いことを示していますか?
  • アプリケーションサーバーは通常、多くの例外を処理し、それらを報告しませんか?
  • これは実行中のアプリケーションのパフォーマンスに影響しますか? (約 45 分の実行で約 11000 の例外がスローされました)

ありがとう、アディティア。

4

2 に答える 2

2
  1. はい、特に開発者はこれらを経験しておらず、少なくともカスタム例外でラップしているためです。それ以外の場合は、警告としてログファイルに出力する必要があります。ロギングライブラリが存在するのには理由があります。
  2. 例外が実際のものである場合は、コードが壊れているか、データセットが変更されていることが原因である可能性があります。エラーが発生している理由を理解するために、少なくとも1つのジョブをトレースすることをお勧めします。以前に1つのジョブでペタバイト単位のデータを処理したことがあるので、それがどれほど苛立たしいことかは理解できますが、このジョブの出力が後で消費されて問題が発生した場合、後で支払う必要があります。
  3. 例外をスローしている計算パスが比較的軽い場合、例外からのIOおよび関数呼び出しは、他の計算と比較して多くのコストがかかります。ただし、45分で11kの例外しか発生しないことを考えると、これは4秒です。確かにこれは悪いことですが、他のアプリケーションも多くのIOを実行していないと仮定すると、これによってジョブがそれほどひどくブロックされることはありません。
于 2012-07-18T04:05:09.100 に答える
1

これに対する明白な応答は、

  1. バッチ ジョブが実行しようとしている多くのことは、おそらく完了していません。
  2. しかし、気が狂った開発者は、catch ブロック内のものを修正しようとして、例外を使い果たしてしまう (偽陰性) ことは決してわかりません。
  3. コードが今まで機能していて例外をスローし始めた場合は、データ セットが変更されているか、開発者が正しい例外をスローしている可能性があります。
于 2012-07-18T03:58:55.493 に答える