¿Cómo detectar las fugas de conexión de SqlServer en las aplicaciones ASP.net?

Question

Actualmente estoy haciendo algunas pruebas de GUI en una aplicación ASP.net 2.0. El RDBMS es SQL Server 2005. El host es Win Server 2003 / IIS 6.0.

No tengo el código fuente de la aplicación porque fue programada por una compañía externa que no publica el código.

He notado que la aplicación funciona bien cuando reinicio IIS, pero después de algunas pruebas, después de haber abierto y cerrado mi navegador durante un par de horas, la aplicación comienza a volverse cada vez más lenta. Me preguntaba si este comportamiento se debió a una mala práctica de conexión de cierre de los programadores: sospecho que hay una fuga de conexión abierta en la base de datos aquí.

Supongo que el recolector de basura .Net eventualmente los cerrará pero ... eso puede tomar un tiempo, ¿no?

Tengo SQL Server Management Studio y noto desde el monitor de actividad que hay bastantes conexiones abiertas en la base de datos.

De todo lo que se dijo anteriormente, aquí hay algunas preguntas relacionadas con la pregunta principal:

1. ¿Hay alguna manera de saber en SQL Server 2005 si las conexiones son abierto porque están esperando a ser utilizado en un grupo de conexión o si Están abiertos porque son utilizados por una aplicación?

2. ¿Alguien sabe del bien? Recursos en línea / papel donde podría aprender a usar el rendimiento Contadores o algún otro tipo de herramientas. para ayudar a localizar este tipo de problemas?

3. Si los contadores de rendimiento son los mejores solución, cuales son las variables que yo debería mirar?

Answer 1

Siempre puedes verificar las cadenas de conexión desde web.config (principalmente si tienen la agrupación de conexiones activada, si tienen algún límite de conexión habilitado).

Además, si está utilizando IIS 6, puede configurar su aplicación web para que use un grupo de aplicaciones por separado y configurar otra opción para el reciclaje de la memoria y los procesos.

Sobre los contadores de rendimiento, puede verificar cuánto tiempo está funcionando el recolector de basura, cuánta memoria está usando la aplicación, etc.

Si tiene acceso a un servidor SQL, puede monitorear las conexiones realizadas desde su aplicación (hay contadores de rendimiento definidos para cada instancia instalada de SQL Server).

Hubo algunos artículos en MSDN Magazine . También puede usar la biblioteca de depuración SOS para adjuntar al proceso de la aplicación y verificarlo manualmente.

Y, si no tiene el código fuente, intente utilizar Reflector para obtener las fuentes de la aplicación (serían muy útiles para la depuración)

@Edición posterior: puede consultar esta pregunta aquí también en stackoverflow.com

Answer 2

Encontré este hilo investigando un problema similar. Se me ocurrió el siguiente sql como una buena forma de depurar conexiones con fugas en SQL Server:

SELECT S.spid, login_time, last_batch, status, hostname, program_name, cmd,
(
      select text from sys.dm_exec_sql_text(S.sql_handle)
) as last_sql
FROM sys.sysprocesses S
where dbid > 0
and DB_NAME(dbid) = '<my_database_name>'
and loginname = '<my_application_login>'
order by last_batch asc

Lo que esto le proporciona es todas las conexiones abiertas en una base de datos particular y el inicio de sesión, junto con el último SQL ejecutado en esa conexión , ordenados por el momento en que se ejecutó ese SQL.

Debido a la agrupación de conexiones, no puede confiar simplemente en el hecho de que hay muchas conexiones por ahí para decirle que tiene una fuga de conexión, ya que la agrupación de conexiones mantendrá las conexiones, incluso si están cerradas correctamente. código. Sin embargo, si tiene una fuga de conexión, lo que verá es que algunas conexiones se "congelan": aparecerán en la consulta anterior y la marca de tiempo "last_batch" nunca cambiará. Las otras conexiones también se mantendrán, pero cada vez que se ejecuta un nuevo sql en ellas, se actualiza la marca de tiempo "last_batch". Entonces, el efecto es que las conexiones congeladas flotarán en la parte superior de esta consulta.

Si tiene el código fuente de la aplicación en cuestión, el hecho de que esto le proporcione el último sql ejecutado en la conexión huérfana es muy valioso para la depuración.

Answer 3

Enfrenté este problema y descubrí que SQL Server Profiler era una gran herramienta. Supervisé el sitio en una breve ejecución de prueba y noté que se crearon muchas conexiones (sp_who) que no fueron reutilizadas por el Grupo de conexiones, así que simplemente abrí SQL Server Profiler y luego verifique si todas las llamadas al SP realizadas desde el código fueron seguidas por una "sp_reset_connection" llamada. Si la llamada no está allí antes del inicio de un nuevo lote, simplemente le falta la primera conexión.

Answer 4

La referencia de MSDN sobre ( contadores de rendimiento de ADO.NET ) es bastante claro acerca de lo que puede buscar al perfilar la aplicación. Puede monitorear los contadores utilizando aplicación perfmon integrada en Windows.

Aparte de eso, sugeriría aprender sobre la agrupación de conexiones ADO.NET. Si realmente sospecha que hay un error en su código, puede echarle un vistazo utilizando Reflector de Red Gate (gratis por ahora) que desmonta la MSIL en C #.

Answer 5

Empezaría mirando las conexiones y los tiempos de actividad, y vería si puede encontrar elementos que mantengan las conexiones abiertas.

Diría que si la solución es reiniciar IIS, también puede mirar el uso de memoria de la aplicación para ver si hay una pérdida de memoria o algo que realmente hace que su huella crezca.

Si las conexiones abiertas fueran un problema, en el monitor de actividad vería un número MUY grande de conexiones sin actividad.

Para los contadores de rendimiento, puede comenzar a buscar en " SQL Server: General Stats " objeto de rendimiento.

Answer 6

Todd Denlinger escribió una clase fantástica http://www.codeproject.com/KB/ database / connectionmonitor.aspx que vigila las conexiones del servidor SQL e informa sobre las que no se han eliminado correctamente en un período de tiempo. Conéctelo a su sitio y le avisará cuando haya una fuga.