2

そのアプリケーションが応答を停止するまで、ますます多くのプライベートバイトを使用するWebサービスがあります。マネージヒープ(主にGen2)は約200〜250 MBを示しますが、プライベートバイトは1GBを超えます。管理対象ヒープの外部でのメモリリークの考えられる原因は何ですか?

私はすでに次のことを確認しました:

  1. 多作の動的アセンブリ(Xmlシリアル化、正規表現など)
  2. セッション状態(オフ)
  3. System.Policy.Evidenceメモリリーク(SP1がインストールされている)
  4. スレッドデッドロック(Joinを使用せず、ロックのみ)
  5. SQLOLEDBの使用(SqlClientを使用)

他にどのような情報源を確認できますか?

4

6 に答える 6

3

アプリがリリース モードで準拠していることを確認します。デバッグ モードでコンパイルしてデプロイすると、イベントが定義されたクラスをインスタンス化するだけで (イベントを発生させる必要さえありません)、小さなメモリ リークが発生します。これらのオブジェクトを長時間にわたってインスタンス化すると、すべてのメモリが使用されます。デバッグ ビルドが使用されたという理由だけで、数時間以内にすべてのメモリを使い果たす Web アプリを見てきました。リリース ビルドとしてコンパイルすると、問題はすぐに永続的に修正されました。

于 2008-11-12T21:15:24.623 に答える
0

次も探します。

  • 読み込み中の COM アセンブリ
  • DB 接続が閉じられていない
  • キャッシュと状態 (セッション、アプリケーション)

ガベージ コレクター (GC) を強制的に実行する (ロード時にそれを実行するページを作成する) か、インストルメンテーションを試してみてください。もう 1 つの方法は、実行し続けて、メモリが不足しているかどうかを確認することです。

考えられるのは、十分なメモリがあり、Windows がアプリにクリーンアップを通知しないことです。これにより、実際にはシステムが必要なときにメモリを再利用できるのに、アプリはより多くのメモリを使用しているように見えます。SQL Server と Exchange はこれを頻繁に行います。アイデアは、リソースがたくさんあるときに不要なクリーンアップを引き起こす理由です。

ロブ

于 2008-11-12T22:01:23.593 に答える
0

トレースが有効になっていないことを再確認してください。アプリがアプリ プールの制限に達するまで、トレースがゆっくりとメモリを消費するインスタンスを見てきました。

于 2009-04-11T14:22:57.663 に答える
0

ガベージ コレクションは、使用可能なメモリが不足しているためにメモリの要求が拒否されるまで実行されません。これにより、メモリ リークが存在しない場合でも、メモリ リークのように見えることがよくあります。

サービス内にイベントとイベント ハンドラはありますか? サービスには静的変数が含まれることが多く、非静的インスタンス オブジェクトに接続された静的インスタンスからイベント ハンドラーを作成している場合、静的インスタンスはインスタンスへの参照を永久に保持するため、インスタンスの解放が停止します。

于 2009-04-03T20:28:47.143 に答える
0

さまざまな時点でスタックのスナップショットを表示し、何がメモリを使用しているかを確認することをお勧めします。アプリケーションが Java を使用している場合、jmap は非常にうまく機能します。Java プロセスの PID を指定するだけです。

他のものを使用する場合は、Lambda Probe ( http://www.lambdaprobe.org/d/index.htm ) を試してください。詳細は表示されませんが、少なくともメモリ使用量が表示されます。

私の JDBC コードで悪いメモリ リークが発生し、数年前に見落としていた JDBC 仕様の変更が原因であることがわかりました (終了ステートメントなどに関して)。Lamdba Probe と jmap を組み合わせて、問題を修正するのに十分なだけローカライズする必要がありました。

乾杯、

-R

于 2008-11-12T22:20:51.077 に答える