Solución:
Lo mejor que puede hacer si puede permitirse usar un depurador es instalar las herramientas de depuración de Windows y usar algo como WinDbg y SOS.dll para averiguar exactamente qué hay en la memoria.
una vez que haya instalado las herramientas, podrá:
- Inicie Windbg.exe con un nivel elevado (como administrador)
- Use “Archivo-> Adjuntar al proceso” y elija w3wp.exe para la aplicación que está tratando de averiguar. Si tiene muchos, puede usar el Administrador de tareas y agregar la columna de la línea de comandos para ver el PID o usar el Administrador de IIS-> Procesos de trabajo para averiguarlo, y luego elegir ese proceso en WinDBG.
- correr:
- .loadby sos clr
- ! dumpheap -stat
En ese punto, debería poder ver todos los tipos ordenados por el mayor consumo de memoria para que pueda comenzar con los que están en la parte inferior. (Recomendaría excluir Strings y Object, ya que suelen ser un efecto secundario y no la causa). Use “! Dumpheap -type type-here” para encontrar las instancias y use! Gcroot para averiguar por qué están en la memoria, tal vez debido a un campo estático, o un controlador de eventos filtrado, canales WCF no eliminados o cosas como que son fuentes comunes.
Acabo de mirar mi servidor y mis grupos usan una memoria de tamaño virtual de 900-1000 MB y un conjunto de trabajo de 380 MB. Mis sitios funcionan sin problemas desde hace algunos años, y he comprobado los sitios desde todos los lados. Mi grupo nunca se recicla y el servidor se ejecuta hasta la próxima actualización de forma continua con un 40% de memoria física libre estable.
Si su memoria no crece continuamente, entonces esta memoria es el código más los datos que establece como estática, constante, la cadena y la posible caché, dentro de su aplicación.
Puede utilizar el explorador de procesos para ver el funcionamiento y la memoria de tamaño virtual.
También puede pensar en ejecutar un perfil contra su código para ver si tiene alguna “pérdida de memoria” u otro problema. Encuentre uno de google: https://www.google.com/search?hl=en&q=asp.net+memory+profiler.
Probablemente no se aplique aquí, pero pensé que lo incluiría en una buena medida. Recientemente tuve un problema en el que mi memoria aumentaba y se agotaba cuando realmente podía limpiar el 80%. Problema: Pensó en 2 conciertos más de lo que realmente hizo, por lo que el GC fue bastante vago. (Se debió a un error de VMware: Windows informaba 8 Gig, pero físicamente solo había 6.4). Ver blog.http: //www.worthalook.net/2014/01/give-back-memory/