El tiempo de espera transcurrido antes de obtener una conexión desde el grupo

Question

Nuestro sitio funciona bien durante el 90% del día, luego, durante nuestras horas punta cuando el tráfico es casi el doble de normal, todo se ralentiza. Los tiempos de carga de página que normalmente son de 1 segundo toman 30 segundos. Al revisar nuestros registros de errores, parece que puede tratarse de un problema de grupo de conexiones. Tenemos 3 servidores web conectados a 1 sql server db. El servidor SQL está volando por debajo del 25% de utilización en todos los núcleos.

Miro el contador de conexiones de usuario en nuestro servidor SQL y veo que durante nuestro pico tenemos más de 400 conexiones de usuario, pero fuera de horario es alrededor de 120+.

Estoy bastante seguro de que solo estamos usando la configuración predeterminada de MS para tratar con nuestro grupo de aplicaciones. ¿Qué puedo hacer para probar para ver si hay un problema en el grupo de aplicaciones? ¿Cuáles son los aspectos negativos de aumentar el tamaño del grupo de aplicaciones a 1000 (y cómo lo hago?).

Gracias!

Answer 1

Esto podría estar relacionado con el hecho de que las conexiones sql no se eliminaron correctamente (se devolvieron a la agrupación). Asegúrese de llamar al SqlConnection.Dispose.

Answer 2

Esto podría ser debido a que el conjunto de conexiones SQL se agota (esto es diferente de la piscina del app.) Se puede comprobar que por increasing the pool size a través de la cadena de conexión:

Integrated Security=SSPI;Initial Catalog=northwind;Max Pool Size=100; 

Pero lo más probable es que su base de datos puede Manténgase al día con el flujo de consultas entrantes. Esto hace que las conexiones esperen a que termine su consulta. Agregar más conexiones ayudará contra las solicitudes de ráfagas, pero no contra el tráfico alto sostenido.

Aquí hay algunas sugerencias para mejorar el rendimiento de su SQL Server bajo sostenida alta carga:

• hardware de lanzar en el problema (especialmente RAM en el servidor SQL Server)
• Adjuntar de SQL Server para el servidor, obtener una huella de un periodo de carga alta, y seguir sus índices sugeridos
• Desde el registro de seguimiento, examinar las consultas largas, y mejorar los junto con un desarrollador de T-SQL

¡Buena suerte, estas cosas pueden ser bastante complejas!

Answer 3

En mi experiencia hay 3 tipos principales de los tiempos de espera que puede recibir de SQL Server:

1) InvalidOperationException - Un fallo para el cliente para obtener una conexión agrupada de su propia piscina antes de que el tiempo de espera especificado en el comando cuerda (por defecto 15 segundos). El grupo del cliente tiene su tamaño máximo y todas las conexiones agrupadas están en uso y permanecen en uso antes de que transcurra el tiempo de espera.

2) SQLException - Tiempo de espera de conexión. El grupo de conexiones del cliente está creando una nueva conexión a la base de datos, pero la base de datos no responde antes del tiempo de espera especificado en la cadena de comandos (por defecto 15 segundos).

3) SQLException - Tiempo de espera del comando. Se obtuvo una conexión, pero el tiempo necesario para que la declaración SQL exista el comando excedió el tiempo de espera especificado en la propiedad CommandTimeout del comando (predeterminado 30 segundos)


Las circunstancias de un servidor que funciona normalmente hasta que se agrega carga son como el caso # 1. He descubierto que los tiempos de espera son muy rápidos, generalmente 2 segundos.

He encontrado la solución a esto es aumentar los hilos máximos en SQL Server. El valor predeterminado es cero; deje que SQL Server decida. He visto casos en los que un servidor fuerte se encuentra con poco uso de recursos, mientras que se ha restringido asignando muy pocos hilos.

Puede aumentar los hilos de fijación MAX con este Transact-SQL:

sp_configure 'max worker threads', 8192 
go 
Reconfigure 

A continuación, reinicie el servicio de SQL.

Por cierto, se puede ver cuántos hilos están asignados actualmente por SQL Server con este comando:

select sum(current_workers_count) from sys.dm_os_schedulers 

Este ajuste roscado hace una enorme diferencia en cómo SQL Server lleva a cabo bajo muchas conexiones. SQL Server deja de responder cuando se queda sin subprocesos.

Answer 4

Cuando recibí este error:

The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached

que era debido al hecho de que yo estaba usando el método SqlCommand.ExecuteQuery() en lugar de SqlCommand.ExecuteNonQuery().

Por ejemplo: Mi llamado procdure original almacenada ser algo como esto:

using (SqlCommand cmd = new SqlCommand()) 
{ 
    cmd.CommandType = System.Data.CommandType.StoredProcedure; 
    cmd.CommandText = "InsertSproc"; 
    cmd.Parameters.AddWithValue("@Value", myValue); 
    cmd.Parameters.AddWithValue("@LoggedDate", myDate); 
    DatabaseManager.instance.ExecuteQuery(cmd); 
} 

El código anterior es lo que lanzó la excepción. Sin embargo, el cambio de la llamada para utilizar ExecuteNonQuery() fija el problema:

using (SqlCommand cmd = new SqlCommand()) 
{ 
    cmd.CommandType = System.Data.CommandType.StoredProcedure; 
    cmd.CommandText = "InsertSproc"; 
    cmd.Parameters.AddWithValue("@Value", myValue); 
    cmd.Parameters.AddWithValue("@LoggedDate", myDate); 
    DatabaseManager.instance.ExecuteNonQuery(cmd); 
} 

Answer 5

tuve este problema con PowerShell y espalda con espalda consultas (Invoke-sqlcmd seguido por otro Invoke-sqlcmd). Ambas consultas implicaron modificaciones de datos. Se resuelve agregando -connectiontimeout 1 a la llamada al parámetro.

Ejemplo:

invoke-sqlcmd "insert into testdb..tab1 (cname) select 'x'" -connectiontimeout 1 
invoke-sqlcmd "update testdb..tab1 set ctr=ctr+1 where cname='aaa'" 

Duración del tiempo de espera puede variar dependiendo del número de filas afectadas.