2011-09-16 22 views
5

Tengo un .NET 4.0 Winform y un .NET 4.0 Windows Service que se conectan a una base de datos SQL 2005/2008 a través de LINQ to SQL. Funciona bien y rápido en nuestro entorno de prueba con un clon perfecto de datos de producción, pero en el entorno de producción, se ejecuta muy lentamente y tiene un bajo uso de CPU y uso de ancho de banda. También noté cientos de tiempos de espera de SQL al día, incluso para las consultas más pequeñas en una base de datos bien indexada. Así que dispararon hasta el Analizador ...Linq-to-SQL y sp_reset_connection

encontré que sp_reset_connection representaron un tercio de la duración total de la CPU de SQL y el 90% de todas las llamadas totales SQL durante una captura de 10 minutos bajo carga.

  • He intentado desactivar & que permite la agrupación de conexiones y jugando con el número de conexiones permitidas y los tiempos de espera de conexión en la cadena de conexión. Ninguno ha tenido ningún efecto.
  • He estado reemplazando mis consultas LINQ con consultas ADO.NET a medida que las encuentro. Estas antiguas consultas de ADO.NET nunca agotan el tiempo de espera. Solo los LINQ.
  • He notado otros problemas importantes de rendimiento en ese servidor, pero no estoy seguro de cómo abordar el tema con el administrador del sistema del cliente.
  • Tengo acceso de administrador en el servidor de aplicaciones donde se ejecuta el servicio. Tengo casi ningún acceso en el servidor de terminal donde ejecutan el Winform, ni al servidor SQL.

  • ¿Cuál es la causa de que sp_reset_connection funcione tan a menudo?

  • ¿Hay alguna forma de eludir estas llamadas sin arrancar todo el LINQ de mi aplicación?
  • ¿Hay alguna forma de reducir el número de llamadas a este procedimiento almacenado?
  • ¿Hay alguna forma de reducir la cantidad de tiempo de procesador que el servidor SQL necesita para estas llamadas?
  • ¿Desbarataré algo más si dejo la agrupación deshabilitada y reemplace ese proc almacenado con, por ejemplo, uno vacío?

Respuesta

4

encontrado algunas otras páginas acerca de esto, se sugiere lo siguiente:

Para su restablecimiento de conexión, abra su conexión DataContext antes de trabajar con él y lo cierran al final.

db.Connection.Open() 
... work... 
db.Connection.Close() 
+2

Aparecerían problemas de contexto de datos 'sp_reset_connection' después de cada comando dentro del bloque' using', a menos que abriera la conexión manualmente (eso es algo que nunca hice porque era contrario a la intuición) o tiene una transacción ambiental (que Siempre lo hice, así que funcionó para mí y ni siquiera me di cuenta por qué). ¿Puedes dar un enlace a "algunas otras páginas"? Me gustaría algo de documentación sobre ese comportamiento. – GSerg

1

sp_reset_connection ocurre cuando un SQLConnection vuelve a la agrupación de conexiones, ahora esto no debería ser un problema.

pero ahora la pregunta es ¿por qué obtienes tiempos de espera? ¿es el servidor sql que no puede hacer frente a la cantidad de transacciones o es que el grupo de conexiones se agota, nunca usó Linq-to-sql pero asegúrese de disponer de todo lo que puede disponer cuando haya terminado con los objetos ...

Editar: la agrupación de conexiones está ahí por una razón retirarlo likly empeorará su rendimiento y eliminar "sp_reset_connection" le dará errores extraños como los datos serán transferidos al siguiente usuario de la conexión ...

para reducir las cantidades de sp_reset_connection ¡la única manera que puede hacer es tratar de reutilizar la misma conexión para tantas consultas como sea posible!

Cuestiones relacionadas