System.Security.Policy.Evidence, Web Services и Blowing LoH - PullRequest
Новая
       26

System.Security.Policy.Evidence, Web Services и Blowing LoH

2 голосов
/ 20 мая 2009

В новом приложении интенсивно используются веб-сервисы. Мы начали регулярно исключать исключения из памяти (поскольку их использование увеличилось). При просмотре дампов памяти я заметил большое количество байтов одного размера []. Глядя на дескрипторы этих байтов [], я заметил, что на них ссылается System.Security.Policy.Evidence

При дальнейшем рассмотрении я определил эти выделения памяти как фактические сборки (dll), в которых были наши классы веб-служб (в частности, две сборки находились в памяти 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 Framework, загружающий сборку веб-сервиса в память для проверки политики безопасности).

В настоящее время одним из единственных решений, которое я вижу, является разделение сборок веб-сервисов на более мелкие сборки, которые ссылаются на библиотеки.

Я запутался, почему .NET Framework должен загружать всю сборку в память для проверки политик и хотел узнать, сталкивался ли кто-то еще с этим и какими были ваши решения.

Спасибо, Dan

1 Ответ

1 голос
/ 17 июня 2009

Я видел то же самое в дампах памяти на Framework 3.5 SP1.

В блоге Тесс рассказывается о том, что эти сборки хранятся в кэше ASP.NET, и что этот кэш сбрасывает сборки, вызывая их перезагрузку. Предполагалось, что кэш будет сбрасывать их, когда в системе недостаточно памяти, что является поведением по умолчанию для всего, что происходит в кэше ASP.NET. Тесс говорит, что исправление решает эту проблему.

Текущая версия System.Web.Services содержит это в методе AddToCache System.Web.Services.Protocols.ServerProcotol: 

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

Обратите внимание, что это явно устанавливает элемент кэша, чтобы никогда не истек и никогда не быть съемным. Я думаю, что это то, что исправление было изменено для решения проблемы - больше нет автоматической очистки кэша.

Теперь в нашем приложении, которое испытывает эту проблему, у нас есть некоторый код, который вручную удаляет все из кэша ASP.NET при определенных обстоятельствах. Я думаю, именно поэтому мы видим проблему: хотя исправление остановило ASP.NET Cache, автоматически удаляя эти сборки из кэша, наш код появляется и очищает кэш вручную.

Интересно, ваше приложение (или какой-либо из его сторонних компонентов) что-то делает с Cache, который может удалять эти элементы?

...