2

Java ERP タイプのアプリケーションがあります。サーバーとクライアント間の通信は RMI 経由です。ピーク時には最大 250 人のユーザーがログインし、そのうち約 20 人が同時に作業しています。これは、ピーク時に常に約 20 のスレッドが稼働していることを意味します。サーバーは問題なく何時間も稼働できますが、突然の応答時間はどんどん長くなります。応答時間は数分です。

Sun の JDK 1.6.0_16 を搭載した Windows 2008 R2 で実行しています。perfmon と Process Explorer を使用して、何が起こっているかを確認しています。唯一奇妙な点は、サーバーの動作が遅くなると、java.exe プロセスが開いたハンドルの数が約 3500 になることです。これが実際の問題であると言っているわけではありません。

問題を特定できるようにするために従うべきガイドラインがあるかどうか、私はただ興味があります。どのツールを使用すればよいですか? ....

4

6 に答える 6

3

このアプリケーションのログ構成にアクセスできますか。

可能であれば、ログ レベルを「DEBUG」に変更する必要があります。リクエストの DEBUG ログをトレースすると、競合ポイントに関する有用な情報が得られる場合があります。

それができない場合は、プロファイラー ツールが役に立ちます。

  • VisualVM (無料で優れた製品)
  • Eclipse TPTP (無料ですが、VisualVM よりも複雑です)
  • JProbe (無料ではありませんが、非常に強力です。私のお気に入りの Java プロファイラーですが、高価です)

アプリケーションが JMX コントロール ポイントを使用して開発されている場合は、JMX ビューアをプラグインして情報を取得できます...

アプリケーションにストレスを与えて問題を引き起こしたい場合 (課金の問題かどうかを検証したい場合)、JMeterなどのストレス ツールを使用できます。

于 2010-08-24T16:09:52.550 に答える
1

ガベージ コレクションが追いつかず、なんらかの理由で "halt-the-world" 収集を開始しているようです。

起動時に JDK で jvisualvm をアタッチし、パフォーマンスが低下したときに収集されたデータを確認します。

于 2010-08-24T16:08:44.533 に答える
0

あなたが説明している問題は非常に典型的ですが、一般的でもあります。原因は、メモリリーク、リソース競合などから、不適切なGCポリシーやヒープ/PermGenスペースの割り当てまで多岐にわたります。アプリケーションの正確な問題を指摘するには、アプリケーションをプロファイリングする必要があります（YourkitやJProfilerなどのツールを知っています）。アプリケーションを賢くプロファイリングする場合、一部のアプリケーションサイクルだけで問題が明らかになります。そうでない場合、プロファイリング自体は非常に簡単ではありません。

于 2010-08-24T16:25:28.210 に答える
0

他の人が言及したGCは別として、スローダウン中に約30秒間、5〜10秒ごとにスレッドダンプを取得してみてください。DB 呼び出し、Web サービス、またはその他の依存関係が遅くなる場合があります。トレッド ダンプを見ると、動いていないように見えるスレッドを確認でき、そのようにして原因を絞り込むことができます。

GC の観点から、これらの時間帯に CPU 使用率を監視していますか? GC が頻繁に実行されている場合、全体的な CPU 使用率が急激に上昇します。

これがSolarisボックスだけなら、prstatがあなたの味方になるでしょう。

于 2010-08-24T16:50:48.403 に答える
0

同様の状況で、簡単なプロファイリング コードを自分でコーディングしました。基本的に、「StopWatch」(LinkedHashMap に基づく) を含む ThreadLocal を使用し、次のようなコードをアプリケーションのさまざまなポイントに挿入します。watch.time("OperationX");

次に、スレッドがタスクを終了した後、私が呼び出すwatch.logTime();と、クラスは次のようなログを書き込みます。[DEBUG] StopWatch time:Stuff=0, AnotherEvent=102, OperationX=150

この後、このログから (コード パスごとに) CSV を生成する単純なパーサーを作成しました。最善の方法は、ヒストグラムを作成することです (Excel を使用して簡単に作成できます)。平均、中、さらにはモードでもだまされる可能性があります。ヒストグラムを作成することを強くお勧めします。

このヒストグラムと一緒に、平均/中/モードを使用して折れ線グラフを作成できます (データを最もよく表すものは、ヒストグラムから決定できます)。

このようにして、どの操作に時間がかかっているかを 100% 正確に確認できます。犯人を特定できない場合は、二分探索が役に立ちます (イベントを細かく分類します)。

本当に原始的に聞こえるかもしれませんが、機能します。また、ライブラリを作れば、どんなプロジェクトでも使えます。本番でも簡単にオンにできるので、それもクールです..

于 2010-08-24T16:32:27.623 に答える
0

このような深刻な問題についてjstack <pid>は、問題の領域を迅速に指摘する必要があります。おそらく、すべてのファンシーを取得する必要はありません。

推測する必要があるとすれば、Hotspot が飛び込んで、不適切に記述されたコードを厳密に最適化したと言えます。Netbeans は、WeakHashMap新しく作成されたオブジェクトを使用してファイル データをキャッシュする場所で停止します。最適化すると、エントリを追加した直後にマップから削除できます。明らかに、キャッシュが依存している場合、多くのファイル アクティビティが続きます。ドライブはすべて OS によってキャッシュされるため、おそらく点灯することはありません。

于 2010-08-24T17:27:32.410 に答える