3

非常に奇妙な問題を示すアプリケーションを実行しています。約 2.5 時間は正常に動作しますが、突然、管理されていないメモリが増加し始め、急速に増加します。さらに約 30 分以内に、アプリがクラッシュします。

アプリケーションはアンマネージ DLL を使用していません。外部アプリケーションと通信しています。ソケット (ストリーム経由で使用) を使用して書き込み、WCF ストリームを介して読み取ります。

ANTSでプロファイリングしました。アンマネージ メモリ使用率の突然の変化は非常に印象的です。永久に完全にフラットなままで、その後突然増加し始め、アプリケーションが失敗するまで一定の速度で増加し続けます。マネージ メモリ内には、場違いに見えるものはありません。

アンマネージ コードを意図的に使用しているわけではないので、リークの原因を特定するのは困難です。ANTSは役に立ちません。最初から着実に増加していない場合、コードをスクラブして問題を解決するのは困難です (アプリは常にアイドル状態のままですが、非常に小さなデータでソケットを介して毎秒 1 回サーバーに ping を実行します)。

繰り返しになりますが、この間、アプリケーションとサーバーは両方ともアイドル状態です。これは、分離されたテスト システム (サーバーとクライアントの両方) で実行されています。漏れているのはクライアントです。

4

2 に答える 2

3

おそらく、DebugDiagを使用してメモリリークを監視し、何が割り当てられ、どれだけ、どのコールスタックから割り当てられたかに関する情報を提供することをお勧めします。要するに：

プロセスが開始（または再開）されたらすぐに、次の手順を実行します。

  1. DebugDiagを開きます。
  2. ウィザードをキャンセルします。
  3. [プロセス]タブに移動します。
  4. 目的のプロセスを右クリックします。
  5. リークの監視を選択します。
  6. [OK]をクリックします。

プロセスがしばらく実行され、メモリの問題が明らかになった後：

  1. DebugDiagに移動します
  2. まだ開いていない場合は、ウィザードをキャンセルします。
  3. [プロセス]タブに移動します。
  4. パート1と同じプロセスを右クリックします。
  5. [完全なユーザーダンプの作成]を選択します。
  6. ダンプの場所をメモします。

また、メモリダンプがキャプチャされる前にプロセスが再開された場合は、リークモニタリングを再度有効にする必要があります。

ダンプを取得したら：

  1. DebugDiagに移動します。
  2. [高度な分析]タブに移動します。
  3. 上部にある「MemoryAnalysis.asp」スクリプトを選択します。
  4. 下部にある[データファイルの追加]をクリックして、前に作成したダンプを選択します。
  5. 「分析の開始」をクリックして、結果を確認します。

その情報を入手したら、メモリ割り当てがどこから来ているのか、そしてうまくいけば問題の原因を特定できるはずです。

次のリソースから詳細情報を見つけることができます。

于 2011-10-12T19:09:13.303 に答える
0

最終的に問題が見つかりました。2 つの間にソケット接続があることが判明し、アイドル フェーズ中に KeepAlive パケットを送信して、リスナーが自動切断されないようにしました。ただし、一定時間アイドル状態になった後、WCF でのいくつかの固有のタイムアウトにより、ソケットがサーバー側で閉じられていました。

したがって、基本的に DispatchTimer が起動するたびに、キープアライブ パケットがソケットに書き込まれますが、明らかにブロックされます。これは、次の DispatchTimer がまったく同じことをするのを止めません。それは何か大きいように見えましたが、これらの小さなパケットは急速に蓄積され、すべての管理されていないメモリを消費していました.ソケットのバッファだと思います（接続に NetworkStream を使用していたと思います）. ロジックを少し変更すると、問題は解消されました。

しかし、すべての入力をありがとう、それは大歓迎でした!

于 2011-11-04T11:21:48.600 に答える