System.Security.Policy.Evidence, Web Services et souffler le LoH

Question

Une nouvelle application qui a été développée utilise beaucoup de services Web. Nous avons régulièrement commencé à utiliser des exceptions de mémoire insuffisante (à mesure que l'utilisation augmentait). En examinant les vidages de la mémoire, j'ai remarqué qu'il y avait un grand nombre d'octets de même taille []. En regardant les poignées pour ces octets [] j'ai remarqué qu'ils ont été référencés par System.Security.Policy.Evidence

Après un examen plus approfondi, j'ai identifié ces allocations de mémoire comme les assemblées réelles (dll) qui avaient nos classes de service Web dans les (2 des assemblées en particulier étaient en mémoire 128 fois et 115 fois). J'ai trouvé quelques informations ici -> blogs.msdn.com/tess/archive/2008/06/25/asp-net-memory-leak-byte-arrays-rooted-in-system-security-policy-evidence. ASPX

et ici -> blogs.javista.com/2009/03/18/best-practices-for-crm-memory-usage/

mais je ne l'ai pas pu trouver beaucoup d'autres références à ce problème. (Framework .NET chargeant l'assembly webservice en mémoire pour vérifier les politiques de sécurité).

Actuellement, une des seules solutions que je vois est de séparer les asseblies des webservices dans des assemblages plus petits qui font référence aux bibliothèques. Je suis confus pourquoi le framework .NET doit charger l'ensemble de l'assembly en mémoire pour vérifier les politiques et a voulu voir si quelqu'un d'autre a rencontré ceci et quelles étaient vos solutions.

Merci, Dan

Answer 1

J'ai vu la même chose dans la mémoire dumps Framework 3.5 SP1.

Le blog de Tess parle de ces assemblages stockés dans le cache ASP.NET et du vidage des assemblys, ce qui entraîne leur rechargement. La suggestion était que le cache les viderait lorsque le système était faible sur la mémoire, ce qui est le comportement par défaut pour tout ce qui se passe dans le cache ASP.NET. Tess dit qu'un correctif résout ce problème.

La version actuelle de System.Web.Services contient cette méthode dans AddToCache de System.Web.Services.Protocols.ServerProcotol:

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

Notez que ceci est la définition explicite l'élément de cache pour ne jamais expirer et jamais amovible. Je suppose que c'est ce que le correctif a changé pour résoudre le problème - plus de vidage automatique du cache.

Maintenant, dans notre application qui rencontre ce problème, nous avons du code qui efface manuellement tout dans le cache ASP.NET dans certaines circonstances. Je pense que c'est la raison pour laquelle nous voyons le problème: bien que le correctif ait arrêté le cache ASP.NET en effaçant automatiquement ces assemblys du cache, notre code arrive et efface le cache manuellement.

Je me demande si votre application (ou l'un de ses composants tiers) est en train de faire quelque chose avec le cache qui pourrait supprimer ces éléments?