¿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).
fuente
RPC:Starting,RPC:Completedy espero tipos por un período corto y luego mirar a través de los datos para ver qué tipos esperar los SPID están encontrando durante ese tiempo.Respuestas:
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.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: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.fuente
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: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.
fuente