2

開発された新しいアプリケーションは、Web サービスを多用しています。定期的にメモリ不足の例外が発生するようになりました (使用量の増加に伴い)。メモリ ダンプを確認すると、同じサイズのバイト [] が多数あることに気付きました。これらの byte[] のハンドルを見ると、それらが 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 つは、Web サービスのアセンブリを、ライブラリを参照する小さなアセンブリに分離することです。

ポリシーをチェックするために .NET フレームワークがアセンブリ全体をメモリにロードする必要がある理由がわかりません。他の誰かがこれに遭遇したかどうか、およびあなたのソリューションが何であるかを確認したかったのです。

ありがとう、ダン

4

1 に答える 1

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 キャッシュがキャッシュからこれらのアセンブリを自動的にクリアするのを停止しましたが、コードが実行され、手動でキャッシュがクリアされています。

あなたのアプリケーション (またはそのサードパーティ コンポーネント) は、これらのアイテムを削除する可能性のあるキャッシュで何かを行っているのでしょうか?

于 2009-06-17T05:07:17.743 に答える