System.Security.Policy.Evidence、Web 服务和消除 LoH
已开发的新应用程序大量使用 Web 服务。 我们开始定期遇到内存不足异常（随着使用量的增加）。 在查看内存转储后，我注意到有大量相同大小的字节[]。 查看这些 byte[] 的句柄，我注意到它们被 System.Security.Policy.Evidence 引用。
经过进一步检查，我将这些内存分配识别为实际的程序集 (dll)，其中包含我们的 Web 服务类（其中的 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/
但我无法找到有关此问题的其他参考资料。 （.NET框架将Web服务程序集加载到内存中以检查安全策略）。
目前，我看到的唯一解决方案之一是将 Web 服务的程序集分成引用库的较小程序集。
我很困惑为什么 .NET 框架必须将整个程序集加载到内存中以检查策略，并想看看其他人是否遇到过这种情况以及您的解决方案是什么。
谢谢， 担
A new application that has been developed has a heavy use of web services. We started hitting out of memory exceptions on a regular basis (as usage has increased). Upon reviewing the memory dumps I noticed there were a large number of same sized byte[]. Looking at the handles for these byte[] I noticed that they were referenced by System.Security.Policy.Evidence
Upon further review I identified these memory allocations as the actual assemblies (dlls) that had our web service classes in them (2 of the assemblies in particular were in memory 128 times and 115 times). I found some information in here -->
blogs.msdn.com/tess/archive/2008/06/25/asp-net-memory-leak-byte-arrays-rooted-in-system-security-policy-evidence.aspx
and here -->
blogs.javista.com/2009/03/18/best-practices-for-crm-memory-usage/
but I have not been able to find much other reference to this issue. (.NET framework loading the webservice assembly into memory to check security policys).
Currently, one of the only solutions I am seeing is to seperate the asseblies of the webservices into smaller assemblies that reference libraries.
I am confused why the .NET framework must load the entire assembly into memory to check the policies and wanted to see if anyone else has encountered this and what your solutions were.
Thanks,
Dan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在 Framework 3.5 SP1 的内存转储中看到了同样的情况。
Tess 的博客讨论了这些程序集存储在 ASP.NET 缓存中，并且缓存刷新了程序集，导致它们被重新加载。 建议是，当系统内存不足时，缓存将刷新它们，这是 ASP.NET 缓存中任何内容的默认行为。 苔丝说修补程序解决了这个问题。
当前版本的 System.Web.Services 在 System.Web.Services.Protocols.ServerProcotol 的 AddToCache 方法中包含此内容：
请注意，这是显式地将缓存项设置为永不过期且永不可移动。 我想这就是修补程序为解决问题所做的更改——不再自动刷新缓存。
现在，在遇到此问题的应用程序中，我们有一些代码可以在某些情况下手动清除 ASP.NET 缓存中的所有内容。 我认为这就是我们看到问题的原因：虽然修补程序阻止了 ASP.NET 缓存自动从缓存中清除这些程序集，但我们的代码正在手动清除缓存。
我想知道您的应用程序（或其任何第三方组件）是否正在对缓存执行任何可能会删除这些项目的操作？
I've seen the same thing in memory dumps on Framework 3.5 SP1.
Tess's blog talks about these assemblies being stored in the ASP.NET Cache, and the Cache flushing the assemblies, causing them to be reloaded. The suggestion was that the Cache would flush them when the system was low on memory, which is the default behaviour for anything that goes in the ASP.NET Cache. Tess says that a hotfix resolves this issue.
The current version of System.Web.Services contains this in System.Web.Services.Protocols.ServerProcotol's AddToCache method:
Note that this is explicitly setting the cache item to never expire and never be removable. I guess this is what the hotfix changed to resolve the issue -- no more automatic cache flushing.
Now, in our application that is experiencing this problem, we have some code that manually clears everything from the ASP.NET Cache under certain circumstances. I think this is why we are seeing the problem: although the hotfix stopped the ASP.NET Cache clearing these assemblies from the cache automatically, our code is coming along and clearing the cache manually.
I wonder if your application (or any of its third-party components) is doing anything with the Cache which might be deleting these items?