Aspectos rápidos que debe comprobar cuando experimente niveles altos de memoria en ASP.NET

  • Artículo
  • Tiempo de lectura: 6 minutos

En este artículo se describen las cosas rápidas que se pueden comprobar cuando se experimenta una memoria alta en Microsoft ASP.NET.

Versión del producto original:   ASP.NET
Número KB original:   893660

Este artículo empezará con algunos problemas comunes, acciones para solucionar estos problemas y una breve explicación de por qué estas situaciones pueden causar problemas.

ASP.NET de voz de soporte técnico

In the April 2005 Support Voice column, we inadvertently provided a link to the wrong file. En lugar de vincular a una descarga para el servicio web, nos vinculamos al archivo XML devuelto por el servicio web. Ese vínculo se ha corregido. Si desea revisar el artículo con el archivo adjunto correcto, vea Actualizaciones dinámicas de página con XMLHTTP.

Lo que se considera memoria alta

Obviamente, esta pregunta depende del volumen y la actividad de aplicaciones específicas. En general, la memoria alta se debe a que la memoria del proceso de trabajo de ASP.NET (Aspnet_wp.exe) o del proceso de trabajo de Internet Information Services (IIS) (W3wp.exe) aumenta constantemente y no vuelve a un nivel cómodo.

En términos generales, un nivel cómodo sería inferior a 600 MB en el espacio de direcciones de memoria de usuario predeterminado de 2 GB. Una vez que el nivel de memoria es mayor que ese nivel cómodo, estamos haciendo menos de lo que deberíamos. Este comportamiento puede afectar a otras aplicaciones que se ejecutan en el sistema.

La clave es comprender que algunas aplicaciones requieren más memoria que otras. Si excede estos límites, puede agregar más memoria o agregar otro servidor a la granja de servidores web (o considerar una granja de servidores web). También se recomienda la generación de perfiles en estos casos. Puede permitir a los desarrolladores crear aplicaciones más sencillas. En este artículo, estamos viendo una situación en la que se ve que la memoria aumenta de forma coherente hasta que el servidor deja de funcionar.

Aplicación configurada para la depuración

Una razón para la memoria alta que vemos aquí en Soporte es cuando tiene la depuración, el seguimiento o ambos habilitados para la aplicación. Al desarrollar la aplicación, es necesario habilitar la depuración y el seguimiento. De forma predeterminada, al crear la aplicación en Visual Studio .NET, verá el siguiente conjunto de atributos en el Web.config archivo:

<compilation
 ...
 debug="true"
 />

o

 <trace
 enabled="true"
 ...
 />

Además, cuando realice una compilación final de la aplicación, asegúrese de hacerlo en modo versión, no en modo depuración. Una vez que esté en producción, la depuración ya no debe ser necesaria. Realmente puede ralentizar el rendimiento y consumir la memoria. Al establecer este atributo, se cambian algunas cosas sobre cómo se administra la aplicación.

En primer lugar, la compilación por lotes se deshabilitará, incluso si está establecida en este compilation elemento. Significa que se crea un ensamblado para cada página de la aplicación de modo que se pueda dividir en él. Estos ensamblados se pueden dispersar aleatoriamente en el espacio de memoria, lo que hace que sea más difícil encontrar el espacio contiguo para asignar memoria.

En segundo lugar, executionTimeout el atributo ( <httpRuntime> Element) se establece en un número alto, reemplazando el valor predeterminado de 90 segundos. Está bien al depurar, ya que no puede tener el tiempo de espera de la aplicación mientras pasa pacientemente por el código para encontrar sus errores. Sin embargo, es un riesgo significativo en la producción. Significa que si tienes una solicitud no fiable por cualquier motivo, se mantendrá en un subproceso y continuará cualquier comportamiento perjudicial durante días en lugar de pocos minutos.

Por último, va a crear más archivos en la carpeta Archivos ASP.NET temporales. Y el System.Diagnostics.DebuggableAttribute espacio de nombres (System.Diagnostics se agrega a todo el código generado, lo que puede provocar una degradación del rendimiento.

Si no obtiene nada más de este artículo, espero que obtenga esta información. Dejar la depuración habilitada es malo. Vemos este comportamiento con demasiada frecuencia y es muy fácil cambiar. Recuerde que se puede establecer en el nivel de página. Asegúrese de que todas las páginas no la están configurando.

Concatenación de cadenas

Hay aplicaciones que crean resultados HTML mediante código del lado servidor y simplemente creando una cadena HTML grande para enviar al explorador. Está bien, pero si está creando la cadena mediante el uso y la concatenación, es posible que no tenga en cuenta cuántas cadenas grandes está + & creando. Por ejemplo:

string mystring = "<html>";
mystring = mystring + "<table><tr><td>";
mystring = mystring + "First Cell";
mystring = mystring + "</td></tr></table>";
mystring = mystring + "</html>";

Este código parece lo suficientemente inofensivo, pero esto es lo que almacena en la memoria:

<html>
<html><table><tr><td>
<html><table><tr><td>First Cell
<html><table><tr><td>First Cell</td></tr></table>
<html><table><tr><td>First Cell</td></tr></table></html>

Puede que piense que está almacenando la última línea, pero está almacenando todas estas líneas. You can see how it could get out of hand, especially when you're building a large table, perhaps by looping through a large recordset. Si es lo que está haciendo, use nuestra clase para almacenar System.Text.StringBuilder la única cadena grande. Vea Usar visual C# mejorar el rendimiento de concatenación de cadenas

.NET Framework Service Pack 1 (SP1)

Si aún no ejecuta el .NET Framework SP1, instale este SP si tiene problemas de memoria. No voy a entrar en grandes detalles, pero básicamente, con SP1 ahora estamos asignando memoria de una manera mucho más eficiente. Básicamente, estamos asignando 16 MB a la vez para objetos grandes en lugar de 64 MB a la vez. Todos nos hemos movido y todos sabemos que podemos empaquetar mucho más en un coche o un camión si estamos usando muchas cajas pequeñas en lugar de unas cuantas cajas grandes. Es la idea aquí.

No tengas miedo a reciclar periódicamente

Reciclamos grupos de aplicaciones en IIS cada 29 horas de forma predeterminada. El Aspnet_wp.exe continuará hasta que finalice la tarea, reinicie IIS o reinicie el equipo. Este comportamiento significa que este proceso podría estar en ejecución durante meses. Es una buena idea que algunas aplicaciones reinicien el proceso de trabajo cada par de días o así, en un momento conveniente.

Preguntas que se pueden hacer

Las anteriores eran todas las cosas que se pueden corregir rápidamente. Sin embargo, si tiene problemas de memoria, haga estas preguntas:

  • ¿Estoy usando muchos objetos grandes? Más de 85 000 KB se almacenan en un montón de objetos de gran tamaño.

  • ¿Estoy almacenando objetos en estado de sesión? Estos objetos permanecerán en la memoria durante mucho más tiempo que si los usa y elimina.

  • ¿Estoy usando el Cache objeto? Cuando se usa con prudencia, es una gran ventaja para el rendimiento. Pero cuando se usa de forma imprudente, se pasa a usar mucha memoria que nunca se libera.

  • ¿Estoy devolviendo recordsets demasiado grande para una aplicación web? Nadie quiere ver 1.000 registros en una página web. Debe diseñar la aplicación para que nunca obtenga más de 50 a 100 registros en un solo viaje.

Depuración

No voy a entrar en la configuración de WinDbg. Pero puede usar los siguientes comandos para ver lo que está exactamente en la memoria, si desea solucionar problemas más complicados.

!eeheap -gc

Este comando le mostrará la cantidad de memoria administrada que tiene. Si este valor es alto, hay algo que el código administrado está creando.

!dumpheap -stat

Este comando llevará bastante tiempo ejecutarse, incluso horas si la memoria es grande. Pero este comando le dará una lista de todos los objetos, cuántos de cada tipo y cuánta memoria está usando cada uno. (Por ejemplo, para la StringBuilder clase, verá muchos System.String objetos)

Una vez que haya encontrado un objeto que toma mucha memoria, busque más con el siguiente comando:

!do <addr>

Puede obtener la dirección del objeto que está buscando en el dumpheap comando.

Intentaremos incorporar más formas de usar esta herramienta de diagnóstico para situaciones específicas en estas columnas. Háganos saber si estamos haciendo un buen trabajo.

Artículos de memoria y rendimiento

Conceptos básicos del recolector de elementos no utilizados y sugerencias de rendimiento

Desarrollo de High-Performance ASP.NET aplicaciones

ASP.NET de rendimiento y Cuándo avisar a los administradores

Mejorar el rendimiento y la escalabilidad de las aplicaciones .NET