私はOutOfMemoryException、私たちのアプリケーション内の一連の問題を診断するために取り組んでいます。これは、コンソール アプリケーション内で実行され、一連のハードウェア コンポーネントと並行して通信する、内部 32 ビット (x86) OWIN でホストされる WebAPI です。そのため、ライブラリの約 20 のインスタンスを作成しており、「仮想サイズ」メモリの急激な増加は、それらのインスタンスが作成されたときに一致します。
Process Explorer と dotMemory の出力から、このアプリケーション内でそれほど多くの実際のメモリを割り当てているようには見えません。
非常に多くのSO回答を読んだことから、私たちの問題はG0、G1、G2、およびLOHヒープ内の断片化によるものか、Windowsで実行されている32ビットプロセスの2GBのアドレス指定可能なメモリ制限にぶつかっている可能性があることを理解していると思います7. このアプリケーションはバッチで動作し、ハードウェア デバイスから大量のデータを収集し、メモリ内にコレクションを作成してそのデータを 1 つのオブジェクトに集約し、それを保存してクライアント アプリで取得できるようにします。このアクティビティが dotMemory ビジュアルのスパイクの原因ですが、これらのデータ構造は巨大ではなく、dotMemory グラフが示していると思います。
ヒープを見ると、サイズが 10 ～ 15 MB を超えることはめったになく、LOH が大きくなりすぎたり、ひどく断片化されたりしているという証拠はあまり見られません。ここで何が起こっているのかをよりよく理解するためにどのように進めればよいのか、私は本当に苦労しています。
だから私の質問は2つあります：
仮想メモリの 2 GB の制限に達している可能性があり、それがこれらのメモリ例外の原因である可能性はありますか?
それが考えられる原因である場合、64ビットビルドがそれを回避すると考えるのは正しいですか?
64 ビット ビルドへの移行を検討していますが、それには、使用しているいくつかの低レベル ライブラリも 64 ビットに更新する必要があります。これは確かに最終的には検討するオプションですが (すぐにではないとしても)、必要な時間を費やす前に、この状況をよりよく理解しようとしています.
LARGEADDRESSFLAG を設定した後に更新する
推奨事項に基づいて、バイナリにそのフラグを設定したところ、興味深いことに、仮想サイズがすぐに 3GB 近くまで跳ね上がりました。私はそれによって警戒する必要があるかどうかわからない?!
今後数時間、この構成でアプリケーションを監視します。