IIS 6.0 アプリケーション プールは、ページの最初の読み込みで 155Mb のメモリを消費します。その後同じページを更新すると、消費されるアプリ プール メモリは最大で約 245Mb になります。
これは Web フォーム アプリケーションであり、Entity Framework と DevExpress コントロールを使用します。
最初はこれはメモリ リークだと思っていましたが、メモリ プロファイラを使用してさらに調査したところ、アプリ プールによって占有されている領域の半分以上が空き領域であり、断片化されていることがわかりました。
これにより、Large Object Heap メモリの断片化が原因であることがわかりました。実際、約 980Kb の長いリストがあり、特にリストが大きくなり、サイズが変更されてメモリに穴が残る場合に、通常、断片化を引き起こす可能性があります。
したがって、基本的にはリストのリストである複合リストを作成しました。各リストは85000バイト未満になるため、ガベージコレクション後に圧縮される通常のヒープに割り当てられるという考えです（Large Object Heapとは異なり、圧縮されることはありません）
他の人がリストのリストを使用してオブジェクトがラージ オブジェクト ヒープから確実に逃れるようにするために、複合リストがそのトリックを実行することを期待していましたが、この場合、実際の違いはないようで、アプリケーション プールのメモリはまだ約 240Mb ですが、メモリ プロファイラーはドット ネット CLR メモリを約 10Mb と報告しています。
何が起こっているのかを確認するためにメモリダンプを実行する予定ですが、他の誰かが考えられる原因について見解を持っているかどうか疑問に思いました.