¿Cuáles son las posibles causas de que sp_reset_connection tarde mucho tiempo en ejecutarse?

¿Por qué el sp_reset_connectionprocedimiento almacenado del sistema tardaría más de unos pocos milisegundos en ejecutarse, tal como se ve a través de SQL Server Profiler?

Tomé un rastro simple de un sistema de producción usando SQL Server Profiler y luego usé SqlNexus para analizarlo. SqlNexus indica que sp_reset_connection tiene la mayor duración acumulativa: 33% de la traza general. La duración observada varía de 0-7 segundos (12 a 6,833,270 microsegundos) pero promedios en 0.956s.

Entiendo que se llama a sp_reset_connection cuando se reutiliza una conexión agrupada. He visto una sugerencia de que esto puede estar sucediendo debido a trazas extrañas , pero ese no parece ser el caso.

He leído lo que está haciendo el servidor cuando se llama al sproc, pero no creo que ninguno de ellos sea problemático en este caso: el código no deja transacciones abiertas o grandes tablas temporales que tendrían que limpiarse.

También miré /server/199974/sp-reset-connection-taking-a-long-time-to-run pero no fue útil.

EDITAR (2013-12-23): en todos los casos, las lecturas y escrituras son 0 y la CPU es casi siempre 0 (solo dos instancias de CPU no cero, ambas a 16 ms).

Finalmente tuve tiempo para escribir una respuesta más detallada.

Por lo general, hay tres razones principales por las que un procedimiento simple como sp_reset_connectiontardará mucho tiempo en ejecutarse.

1. Estás esperando recursos de CPU
2. Está bloqueado en un candado en algún lugar (tal vez como resultado de DML o una transacción de la competencia)
3. Su red es lenta y lleva mucho tiempo devolver el resultado al cliente

Anuncio 1) Si está esperando recursos de CPU, esto debería aparecer como señales en espera. Consulte mi comentario sobre su pregunta sobre cómo diagnosticar si este es el problema

Anuncio 2) Si está esperando un bloqueo, esto se diagnostica mejor comparando dos instantáneas de sys.dm_os_wait_stats. Vea este artículo sobre cómo hacer esto:

• http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Si ve largas esperas para LCK_ [Algo], consulte sys.dm_tran_lockspara rastrear qué objetos se están bloqueando. En su caso, esperaría ver alguna forma de SCH- [Algo]> bloqueos que lo bloqueen.

Anuncio 3) La forma más fácil de diagnosticar problemas de red para buscar OLEDB y ASYNC_NETWORK_IO primero espera en el paso 2 (si espera mucho tiempo para la red, uno de esos aparece). Si esas esperas son altas, use xperf -on latencyun programa de monitoreo de red como netmon o wireshark para verificar sus latencias. Si la red parece lenta, esto también podría deberse a que el servidor de la aplicación que realiza la llamada no responde lo suficientemente rápido a la conexión que se recicla.

Acabo de encontrar un artículo de KB para un error que puede estar relacionado con este problema. En FIX: los problemas de rendimiento se producen cuando la actividad de bloqueo de la base de datos aumenta en SQL Server (KB 2926217), uno de los síntomas descritos es que sp_reset_connectionpuede tardar mucho tiempo en completarse. La revisión se incluye en las siguientes actualizaciones:

• Actualización acumulativa 17 para SQL Server 2008 SP3
• Actualización acumulativa 13 para SQL Server 2008 R2 SP2
• Actualización acumulativa 9 para SQL Server 2012 SP1
• Actualización acumulativa 1 para SQL Server 2014

El servidor en el que observé este comportamiento ejecutaba SQL Server 2008 SP3 con la actualización acumulativa 5, por lo que es posible que esté experimentando este error. Todavía no he probado la actualización acumulativa (el problema no se repite todo el tiempo), así que no puedo verificar si lo solucionará o no. Sin embargo, quería proporcionar la información en caso de que alguien tuviera los mismos síntomas.