2010-11-01 4 views
2

J'ai une application asp.net, elle fonctionne sur DotNetNuke, sous charge, nous obtenons occasionnellement une exception de mémoire insuffisante.Obtention d'une exception de mémoire insuffisante avec System.Threading.ReaderWriterCount

J'ai une décharge chargée dans windbg.

la fin! Dumpheap -stat est

1192a588 88684  2128416 AutoMapper.MappingEngine 
79333594  9482  2266348 System.Byte[] 
134b0034 88695  2838240 System.EventHandler`1[[AutoMapper.TypeMapCreatedEventArgs, AutoMapper]] 
13d8703c 88684  4611568 System.Collections.Generic.Dictionary`2[[Castle.DynamicProxy.Generators.CacheKey, AutoMapper],[System.Type, mscorlib]] 
13d86dc8 88684  4611568 Castle.DynamicProxy.ModuleScope 
13d865bc 88684  4611568 System.Collections.Generic.Dictionary`2[[AutoMapper.Internal.TypePair, AutoMapper],[AutoMapper.IObjectMapper, AutoMapper]] 
79327434 88703  4612556 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.Int32, mscorlib]] 
6c38e4e4 88684  5675776 System.Threading.ReaderWriterLockSlim 
79330b24 87736  6458012 System.String 
000d9c88  129  24186884  Free 
793042f4 221202 101117016 System.Object[] 
6c38e4a0 22703104 544874496 System.Threading.ReaderWriterCount 

Je ne trouve pas beaucoup d'informations sur le System.Threading.ReaderWriterCount, comme cela semble être le problème.

Quelle est la cause probable? Ou à défaut, quelle est la meilleure étape suivante pour y arriver?

Basé sur le pointeur de la réponse donnée, j'ai regardé ReaderWriterLockSlim. Je ne l'utilisais pas directement, mais j'ai vu qu'il avait 88684 instances, en creusant plus profond j'ai vu quelques classes avec ce nombre d'instances, en pointant sur AutoMapper.MappingEngine. Cela devrait être un singleton, alors j'ai jeté un oeil à l'endroit où il est créé. Je soupçonne que c'est le conteneur DI et ai fait quelques changements autour de cela pour voir si cela aide

+0

J'ai eu quelques classes causant ce problème. Ils créaient des instances supplémentaires du moteur de mappage, d'autres classes étaient conservées alors qu'elles n'auraient pas dû l'être. J'ai fini par découpler une classe enfant d'un service (elle avait conservé une référence) et le service pouvait alors être récupéré et la mémoire libérée. – baralong

Répondre

2

ReaderWriterLockSlim n'est pas une classe bon marché dans l'empreinte mémoire - c'est peut-être pourquoi vos instances ReaderWriterCount prolifèrent. Voir here pour des informations détaillées de Reflector. Pouvez-vous réduire l'utilisation de cette classe? Peut-être pas tous d'entre eux doivent être en lecture/écriture Serrures, simple Mutex/lock() pourrait fonctionner?

Notez également que cette classe est IDisposable - peut-être n'êtes-vous pas Dispose() après avoir terminé avec eux?

+0

Merci, même si la chose étrange est que je n'utilise pas ReaderWriterLockSlim, au moins pas dans mon code. J'utilise linq to sql, et Oracle.DataAccess. Des idées sur ce qui pourrait l'utiliser, ou comment je peux le découvrir? – baralong

+0

@baralong - vous avez besoin de quelque chose comme le suivi d'objet .Net dans Visual Studio 2010 (également les versions antérieures): http://msdn.microsoft.com/en-us/library/dd264934.aspx –

Questions connexes