Conexión de rechazo de SQL en la prueba de carga

Estoy ejecutando una prueba de carga en mi sistema. A un cierto nivel de carga, comienzo a recibir errores de SQL en mi registro:

System.Data.SqlClient.SqlException (0x80131904): Se produjo un error específico de la instancia o relacionado con la red al establecer una conexión a SQL Server. El servidor no se encontró o no estaba accesible. Verifique que el nombre de la instancia sea correcto y que SQL Server esté configurado para permitir conexiones remotas. (proveedor: Named Pipes Prprovidererror: 40 – No se pudo conectar a SQL Server) —> System.ComponentModel.Win32Exception (0x80004005): no se encontró la ruta de acceso a la red

Al ejecutar el monitor de rendimiento en el servidor SQL en cuestión, encontré lo siguiente:

  • El nivel de CPU rara vez supera el 50%. (En una iteración anterior, vi que estaba llegando al máximo al 100%, por lo que aumenté las especificaciones de la VM, lo que ayudó a llevar el problema a un nivel de carga más alto).
  • El número de conexiones de usuarios llegó a una sombra superior a 8,000. El servidor Sql tiene la configuración predeterminada de 32,767 conexiones máx.
  • La cadena de conexión especifica un tamaño de grupo máximo de 1000 conexiones a cada base de datos, y hay 100 bases de datos en el servidor. La prueba de carga se distribuye aleatoriamente entre las 100 bases de datos, por lo que debería haber una distribución bastante uniforme, es decir, aproximadamente 80 conexiones por base de datos. En ningún lugar cerca del límite de 1k.

¿Qué otros factores podrían hacer que el Servidor SQL no pueda aceptar conexiones?

ACTUALIZACIÓN: información adicional: estoy usando Entity Framework Core (EF7) para mis conexiones de base de datos, si eso ayuda.

“Ruta de red no encontrada” no parece ser un error relacionado con la capacidad de SQL Server. Como un antiguo “IT Guy”, sospecho que un firewall está eliminando tus paquetes. Si esto ocurre durante una prueba de esfuerzo, el firewall podría interpretar las numerosas solicitudes como un ataque de denegación de servicio y usar algún tipo de regla predefinida para interrumpir las conexiones durante un período de tiempo específico.

¿Cuál es su entorno de red? Si tiene un firewall o enrutador de hardware con capacidades IPS, revisaría esos registros para ver si encuentra una pistola humeante. Es posible que tenga que crear una regla especial para permitir el tráfico ilimitado a su servidor SQL.

Es un poco curioso que tengas tantas conexiones con la base de datos. Debe utilizar la agrupación de conexiones; incluso bajo carga intensa, la agrupación de conexiones debería reducir en gran medida el número de conexiones activas que se utilizan.

¿Puede proporcionar el código que está accediendo a la base de datos? ¿Está llamando al método dispose () o cerrando la conexión?

Además, ¿has mirado para ver si el acceso a datos de datos facilitaría la carga de la base de datos? Un datacache de 2 a 5 segundos puede reducir considerablemente las llamadas a la base de datos.

Se está ejecutando en el límite de retraso de listen() TCP para el puerto de escucha del servidor SQL. Cuando esto sucede, las plataformas Windows (pero no las plataformas * nix) emitirán “conexión rechazada” para las conexiones entrantes.

No soy un tipo de SQL Server, pero es probable que haya un parámetro en algún lugar por el que pueda boost su atraso en la escucha.

Alternativamente, debería considerar una mejor o más agrupación de conexiones en el cliente.

Resulta que el problema no estaba en SQL en absoluto. El problema estaba en nuestro servidor de API, donde algunas de las API estaban escindiendo cientos de subprocesos paralelos, cada uno haciendo su propia conexión a la base de datos. La carga era simplemente demasiado para el servidor de API y comenzó a devolver excepciones de “Acceso denegado” sin siquiera intentar conectarse a la base de datos.

Solución: aceleramos el número de subprocesos que se están escindiendo, utilizando el patrón que se muestra en esta respuesta .