¿Cómo detectar las conexiones de SqlServer en una aplicación ASP.net?

sql-server connection-pooling

Question

Actualmente estoy haciendo algunas pruebas 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 programado por una compañía externa que no está lanzando el código.

Me di cuenta de que la aplicación funciona bien cuando reinicio IIS, pero después de algunas pruebas, después de abrir y cerrar mi navegador durante un par de horas, la aplicación comienza a ir 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: estoy sospechando una fuga de conexión abierta en la base de datos aquí.

Supongo que el recolector de basura de .Net eventualmente los cerrará, pero ... eso puede llevar 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 dicho anteriormente, aquí hay algunas preguntas relacionadas con la pregunta principal:

1. ¿Hay alguna manera de saber en SQL Server 2005 si las conexiones están abiertas porque están esperando ser utilizadas en un grupo de conexiones o si están abiertas porque las usa una aplicación?

2. ¿Alguien sabe de buenos recursos en línea / papel donde podría aprender a usar contadores de rendimiento u otro tipo de herramientas para ayudar a rastrear este tipo de problemas?

3. Si los contadores de rendimiento son la mejor solución, ¿cuáles son las variables que debería ver?

Answer 1

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

Yo diría que pensé que si la solución es reiniciar IIS, también podría mirar el uso de la 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á una MUY gran cantidad de conexiones sin actividad.

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

Answer 2

La referencia de MSDN sobre ( contadores de rendimiento ADO.NET ) es bastante clara acerca de lo que puede buscar al crear un perfil de la aplicación. Puede supervisar los contadores utilizando la aplicación perfmon integrada en Windows.

Aparte de eso, sugiero aprender sobre la agrupación de conexiones ADO.NET. Si realmente sospechas de un error en su código, puedes echarle un vistazo utilizando el reflector de Red Gate (gratis por ahora) que desensambla el MSIL en C #.

Answer 3

Me enfrenté a este problema y descubrí que SQL Server Profiler era una gran herramienta, supervisé el sitio en una breve prueba y noté que se creaban muchas conexiones (sp_who) que Connection Pool no reutilizaba, así que acabo de abrir SQL Server Profiler y luego verifique si todas las llamadas a SP hechas desde el código fueron seguidas por una llamada "sp_reset_connection". Si la llamada no está allí antes del inicio de un nuevo lote, simplemente le falta la primera conexión.

Answer 4

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

Answer 5

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 loginame = ''<my_application_login>''
order by last_batch asc

Lo que esto le proporciona son 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 únicamente en el hecho de que existen muchas conexiones para decirle que tiene una fuga de conexión, porque la agrupación de conexiones mantendrá las conexiones incluso si se cierran correctamente desde el código. Sin embargo, si tiene una fuga de conexión, lo que verá es que algunas conexiones se "congelan": se mostrará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 ejecute un nuevo sql en ellas, la marca de tiempo "last_batch" se actualiza. Entonces, el efecto es que las conexiones congeladas flotarán a 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 6

Siempre puede verificar las cadenas de conexión desde web.config (principalmente si tienen la agrupación de conexiones activada, si tienen límites de conexión habilitados).

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

Acerca de los contadores de rendimiento, puede verificar cuánto tiempo se está ejecutando el recolector de elementos no utilizados, cuánta memoria está usando la aplicación, etc.

Si tiene acceso al servidor sql, puede supervisar 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 podría usar la biblioteca de depuración de SOS para adjuntarlo 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)

@Lite edit: también puedes consultar esta pregunta en .com