Tengo un servicio de Windows multiproceso que he desarrollado con VS 2010 (.NET 4.0) que puede tener desde unas pocas docenas de subprocesos, cada uno recuperando datos de un servidor lento a través de Internet y luego usando una base de datos local para registrar estos datos (por lo que el proceso está vinculado a Internet, no a la LAN ni a la CPU).Múltiples tiempos de espera simultáneos de conexión SQL en multiproceso de Windows Servicio
Con cierta regularidad, estoy consiguiendo una inundación/ráfaga/ráfaga del error de seguimiento de varios hilos simultáneamente:
System.Data.SqlClient.SqlException (0x80131904): Tiempo de espera agotado. El período de tiempo de espera transcurrido antes de la finalización de la operación o el servidor no responde.
La pila de llamadas para este error es típicamente:
en System.Data.ProviderBase.DbConnectionPool.GetConnection (DbConnection owningObject)
en System.Data.ProviderBase.DbConnectionFactory.GetConnection (DbConnection owningConnection)
en System.Data.ProviderBase.DbConnectionClosed.OpenConnection (DbConnection outerConnection, DbConnectionFactory ConnectionFactory)
en System.Data.SqlClient.SqlConnection.Open()
no estoy especificando un tiempo de espera de conexión en la cadena de conexión, y hay otras aplicaciones y procesos de trabajo en esta base de datos. ¿Alguien ha encontrado este tipo de comportamiento y, de ser así, qué se hizo para evitarlo?
El método más comúnmente llamado en mi capa de acceso de datos se parece a esto, y todos mis otros métodos DAL seguir el mismo enfoque:
using (SqlConnection con = new SqlConnection(GetConnectionString()))
using (SqlCommand cmd = new SqlCommand("AddGdsMonitorLogEntry", con))
{
cmd.CommandType = CommandType.StoredProcedure;
/* setting cmd.Parameters [snipped] */
// We have been getting some timeouts writing to the log; wait a little longer than the default.
cmd.CommandTimeout *= 4;
con.Open();
cmd.ExecuteNonQuery();
}
Gracias mucho!
EDITAR
Teniendo en cuenta los comentarios acerca de que esto ocurra en entornos de espejo, que debe mencionar que de hecho la base de datos en cuestión se refleja. Está marcado en SSMS como "Principal, Sincronizado", en el modo "Alta seguridad sin conmutación por error automática (síncrono)".
EDITAR 5/26/11
estoy viendo nada en los registros de SQL Server para indicar algún problema. (No tengo acceso al Visor de eventos de Windows en ese servidor, pero solicité que alguien me busque.)
También estoy viendo exactamente el mismo problema, con la misma stacktrace. La base de datos a la que se conecta se duplica y la cadena de conexión especifica un asociado de conmutación por error. No he podido reproducir el mismo problema desde mi escritorio local, abriendo un montón de conexiones y, al no cerrarlas nunca, aparece un mensaje de excepción diferente. – BrandonAGr
Estos enlaces informan sobre un problema similar, pero ninguno ofrece una solución: [1] (http://stackoverflow.com/questions/3140738/why-timeout-may-occur-in-sqlconnection-open) [2] (http: //blog.brianhartsock.com/2009/09/29/interesting-sql-server-mirroring-problem/) [3] (http://social.msdn.microsoft.com/Forums/en/sqldatabasemirroring/thread/918e4a7f -1fc5-4679-958f-4c4f07b6ae76) [4] (http://social.msdn.microsoft.com/Forums/en/adodotnetdataproviders/thread/e93fae99-a832-407f-9e80-f7a27b1c6194) [5] (http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/thread/d3798fe7-fc7f-45aa-87ca-cd365abc4b55) – BrandonAGr
Creo que el problema no está en la conexión, cliente o base de datos. Pero en consultas ejecutadas. Verificarlos, p. reunir estadísticas de qué SP/consultas plantea una excepción más a menudo – abatishchev