System.Security.Policy.Evidence、Webサービス、LoHの吹き出し

Question

開発された新しいアプリケーションは、Webサービスを多用しています。私たちは定期的にメモリ使用量の例外を使い始めました（使用量が増えたため）。私が気付いたメモリダンプを見直すと、同じ大きさのバイト[]が多数ありました。これらのバイトのハンドルを見ると、System.Security.Policy.Evidenceによって参照されていることに気付きました。

私はこれらのメモリ割り当てを、Webサービスクラスを持つ実際のアセンブリ（dll） （特にアセンブリのうちの2つは128回と115回のメモリにあった）。私はここにいくつかの情報を見つけました - > blogs.msdn.com/tess/archive/2008/06/25/asp-net-memory-leak-byte-arrays-rooted-in-system-security-policy-evidence aspxの

、ここで - > blogs.javista.com/2009/03/18/best-practices-for-crm-memory-usage/

が、私は多くの他の参照を見つけることができませんでしたこの問題に。 （セキュリティポリシをチェックするためにWebサービスアセンブリをメモリにロードする.NETフレームワーク）。

現在のところ、私が見ている唯一の解決策の1つは、ライブラリを参照するより小さなアセンブリにウェブサービスのアサーションを分離することです。

.NETフレームワークがポリシーをチェックするためにアセンブリ全体をメモリにロードして、他の誰かがこの問題に遭遇したか、ソリューションが何であったかを知りたいと思っていたのは混乱します。

おかげで、 ダン

Answer 1

私はFramework 3.5のSP1でメモリダンプで同じものを見てきました。

Tessのブログでは、これらのアセンブリがASP.NETキャッシュに保存され、キャッシュによってアセンブリがフラッシュされて再読み込みされることが説明されています。その提案は、システムがメモリ不足のときにキャッシュがフラッシュするというものでした。これは、ASP.NETキャッシュに格納されているもののデフォルトの動作です。 Tessによれば、修正プログラムはこの問題を解決します。

System.Web.Servicesの現在のバージョンは、System.Web.Services.Protocols.ServerProcotolのAddToCache方法でこれを含んでいます。これは、明示的に有効期限は、決してこと決してしてキャッシュ項目を設定していることを

 HttpRuntime.Cache.Insert(this.CreateKey(protocolType, serverType), value, null, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, CacheItemPriority.NotRemovable, null); 

注意リムーバブル。これは問題を解決するために修正プログラムが変更されたものだと思います。これ以上の自動キャッシュフラッシュはありません。

この問題が発生しているアプリケーションでは、特定の状況下でASP.NETキャッシュからすべてを手動で消去するコードがあります。私たちはこれが問題を抱えている理由だと思います。ホットフィックスはASP.NETキャッシュを停止してこれらのアセンブリを自動的にキャッシュから消去しましたが、私たちのコードは自動的にキャッシュをクリアしています。

あなたのアプリケーション（またはそのサードパーティのコンポーネント）がキャッシュを使ってこれらのアイテムを削除している可能性があるのだろうかと思いますか？