2012-03-12 14 views
23

Tengo una aplicación de sitio web ejecutándose en su propio grupo de aplicaciones en IIS 7.0. La aplicación es un sitio web ASP.NET MVC 3.Uso de memoria alta con el grupo de aplicaciones w3wp IIS 7

He notado que el uso de la memoria para estas aplicaciones correspondiente w3wp El servicio de trabajo IIS es bastante alto (800 MB, con algunas fluctuaciones).

estoy tratando de diagnosticar el problema y han intentado el siguiente:

He inhabilitado el almacenamiento en caché de página de salida para el sitio web a nivel IIS y luego se recicla el grupo de aplicaciones. Esto hace que el proceso w3wp se reinicie. El uso de la memoria para este proceso sube lentamente hasta unos 800 MB, tarda unos 30 segundos en hacerlo. No hay solicitudes de página en este momento. Cuando reinicio el sitio web desde IIS, el tamaño de la memoria del proceso no se altera.

He intentado ejecutar una copia de depuración de la aplicación de VS 2010, no hay problemas con el uso de la memoria.

Algunas ideas que tengo/preguntas son:

¿Este problema relacionado con el código de sitios web? - Dado que los cohetes de memoria antes de que se hayan enviado/gestionado las solicitudes de página, supongo que esto NO es un problema de código.

La aplicación integrada en MVC no tiene en cuenta el almacenamiento en caché.

El sitio web utiliza la visualización de datos en tiempo real, utiliza las solicitudes ajax periódicamente, y generalmente se deja 'abierto' durante largos períodos de tiempo.

¿Por qué el uso de la memoria aumenta después de que la aplicación se recicla y no se envían solicitudes de los usuarios? ¿Esto es porque está cargando información del viejo caché en su memoria del disco?

La aplicación no se cae, sólo estoy preocupado por el uso de la memoria, no es tan grande de un sitio web ...

Cualquier idea/ayuda con llegar al fondo de este problema sería apreciada .

Respuesta

14

Acabo de mirar mi servidor y mis grupos utilizan 900-1000MB de memoria de tamaño virtual y 380 MB de conjunto de trabajo. Mis sitios se ejecutan sin problemas desde hace algunos años, y los he comprobado por todos lados. Mi grupo nunca se recicla y el servidor se ejecuta hasta la próxima actualización de forma continua con una memoria física libre del 40% estable.

Si su memoria no continúa, esta memoria es el código más los datos que establece como estáticos, const, la cadena y el posible caché, dentro de su aplicación.

Puede usar process explorer para ver la memoria de trabajo y la 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. Encuentra uno de google: https://www.google.com/search?hl=en&q=asp.net+memory+profiler.

+1

BTW - Se encontrará estable en un 40% porque, de forma predeterminada, el modelo de proceso en IIS está limitado a utilizar solo el 60% de la memoria disponible. Puede cambiar esto a través de la configuración de processModel memoryLimit. – ProVega

+0

@ProVega Actualmente, junto a IIS, se encuentra el servidor ms sql y el programa de copia de seguridad ms. El programa de copia de seguridad ms puede consumir toda la memoria libre haciendo que el sistema sea lento. Entonces, el servidor MS SQL también puede consumir mucha memoria para el caché, por lo que he configurado los límites máximos de memoria. Así que termino teniendo algo de memoria libre porque tengo que verificar esto. – Aristos

+0

también en la ventana emergente de configuraciones avanzadas de la aplicación, configurar Activar aplicaciones de 32 bits en true también reduce el uso de memoria. consulte esta publicación para obtener información http://www.sitefinity.com/developer-network/forums/bugs-issues-/app-pool-memory-drastically-different-from-32-64-bit –

17

Lo mejor que puede hacer si puede permitirse usar un depurador es instalar el Windows Debugging Tools y usar algo como WinDbg y SOS.dll para averiguar exactamente qué es lo que hay en la memoria.

una vez que haya instalado las herramientas a continuación, se puede:

  1. lanzamiento WinDbg.exe funcionamiento elevado (como administrador)
  2. Uso "Archivo-> conectar con el proceso" y elija w3wp.exe para el aplicación que estás tratando de descubrir. 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 IIS-> Procesos de trabajo para resolverlo, y luego elegir ese proceso en WinDBG.
  3. de ejecución:
  4. .loadby sos CLR
  5. dumpheap -stat

En ese momento usted debería ser capaz de ver todos los tipos ordenados por el consumo de más memoria para que pueda comenzar con los que está en El fondo. (Recomendaría Excluir Cadenas y Objetos, ya que estos suelen ser un efecto secundario y no la causa). Utilice "! Dumpheap -type type-here" para encontrar las instancias y use! Gcroot para que descubran por qué están en la memoria, quizás debido a un campo estático, o un controlador de evento filtrado, canales WCF no eliminados, o cosas así son fuentes comunes.

3

Probablemente no se aplique aquí, pero pensé que lo lanzaría en buena medida. Recientemente tuve un problema en el que mi memoria aumentaría y se agotaría cuando podría limpiar el 80% de ella. Problema: Pensó que se trataba de 2 conciertos más de lo que realmente hizo, por lo que el GC fue bastante vago. (Se debió a un error de VM ware -windows estaba informando 8 Gig, pero físicamente solo había 6.4). Ver blog. http://www.worthalook.net/2014/01/give-back-memory/

0

Algo que podría ayudar: si "reescribe" (abre/guarda) el archivo web.config, su aplicación se reiniciará, debe controlar el uso de memoria desde ese punto. Si sigue creciendo durante el uso, esto podría significar pérdida de memoria o almacenamiento en caché insano. Es posible que pueda identificar qué acciones en su sitio conducen a un aumento de la memoria. Durante mucho tiempo, el uso de la memoria de una aplicación debe ser estable.

Cuestiones relacionadas