Número máximo de conexiones de usuario


24

En SQL Server 2012 Standard edition, sé que el número máximo de conexiones de usuario es 32,767. ¿Qué debo hacer como DBA si me dirijo a este número?

Actualmente hay 30,000 conexiones de usuarios, y se espera que este número aumente.

ingrese la descripción de la imagen aquí


55
Si son de una aplicación, la aplicación debe cerrar su conexión una vez que haya terminado. Dejar una conexión abierta es una posible razón para alcanzar este límite
Mark Sinkinson

Respuestas:


31

El número máximo de conexiones en las versiones y ediciones de SQL Server es 32,767.

Puede determinar cuántas conexiones tiene actualmente SQL Server mirando:

SELECT ConnectionStatus = CASE WHEN dec.most_recent_sql_handle = 0x0 
        THEN 'Unused' 
        ELSE 'Used' 
        END
    , CASE WHEN des.status = 'Sleeping' 
        THEN 'sleeping' 
        ELSE 'Not Sleeping' 
        END
    , ConnectionCount = COUNT(1)
FROM sys.dm_exec_connections dec
    INNER JOIN sys.dm_exec_sessions des ON dec.session_id = des.session_id
GROUP BY CASE WHEN des.status = 'Sleeping' 
        THEN 'sleeping' 
        ELSE 'Not Sleeping' 
        END
    , CASE WHEN dec.most_recent_sql_handle = 0x0 
        THEN 'Unused' 
        ELSE 'Used' 
        END;

Si la relación entre las conexiones usadas y no usadas de la consulta anterior es preocupante, es probable que las aplicaciones cliente conectadas al servidor habiliten la agrupación de conexiones, y esas conexiones no se usan de manera eficiente. Es posible que desee que los desarrolladores modifiquen la cadena de conexión para estas aplicaciones para limitar el tamaño del grupo de conexiones y asegurarse de que están eliminando las conexiones correctamente. Si las conexiones no se eliminan correctamente, permanecerán abiertas mientras se ejecute la aplicación cliente.

Si se siente particularmente rabioso y necesita deshacerse de todas las conexiones que no han realizado nada recientemente (independientemente de si actualmente están realizando un trabajo), puede ejecutar el siguiente código, que generará una lista de sesiones que puede ser asesinado Debería copiar y pegar los comandos generados en una nueva ventana SSMS para ejecutar los comandos. También recomiendo tener su currículum actualizado por si acaso .

DECLARE @cmd NVARCHAR(MAX);
SET @cmd = '';
SELECT @cmd = @cmd + 
    CASE WHEN @cmd = '' THEN '' ELSE CHAR(13) + CHAR(10) END 
    + 'KILL ' + CONVERT(VARCHAR(MAX), dec.session_id) + ';'
FROM sys.dm_exec_connections dec
WHERE dec.most_recent_sql_handle = 0x0;

PRINT @cmd;

Es posible escalar linealmente el número de conexiones más allá de 32,767 al dividir los datos en múltiples nodos de SQL Server. Sin embargo, en mi opinión, usar fragmentos como una forma de superar el límite en el número de conexiones es similar a usar una bomba atómica para matar una araña. Se va a matar a la araña, pero sólo podría tener problemas mayores al final del día. Sin mencionar que es bastante difícil construir una bomba atómica, sin mencionar implementar el fragmentación correctamente.


1
¿Puede explicar por qué deberíamos identificar las sesiones "eliminables" mediante el uso de most_recent_sql_handle en las conexiones sys.dm_exec_ en lugar de utilizar, por ejemplo, status y last_request_start_time e is_user_process en las sesiones sys.dm_exec_ ? Parece una elección extraña.
Mike Sherrill 'Cat Recall'

Ese es un buen punto, @Mike: en ese momento estaba pensando exclusivamente en las conexiones que se han abierto mediante la agrupación de conexiones y que nunca se han utilizado. Sería una buena idea agregar el is_user_processcalificador, y ciertamente no estaría de más excluir las sesiones que tienen algo last_request_start_timeque es algo reciente. ¿Qué tan reciente? Otra buena pregunta.
Max Vernon

El last_request_start_time probablemente debería ser más antiguo que nuevo. Creo que una sesión de usuario "eliminable" de forma segura sería una que esté durmiendo y no haya recibido una solicitud durante un par de días. Supongo que el tiempo límite depende de cuán buenos sean nuestros programadores de aplicaciones para limpiar después de ellos mismos.
Mike Sherrill 'Cat Recall'

12

Me he encontrado con un comportamiento extraño con la agrupación de conexiones en el pasado, y su escenario se alinea bien con una de esas situaciones. Si su aplicación está usando la agrupación de conexiones (y eso sigue siendo una especulación, en este punto, hasta que confirme o niegue eso), entonces tendrá muchas conexiones que permanecerán abiertas. Esto es por diseño.

La agrupación de conexiones tiene como objetivo reducir la sobrecarga de crear una conexión de base de datos. Tomemos, por ejemplo, un grupo de conexiones de 3. Por lo que puedo decir, el ciclo de vida es algo como esto (comenzando desde un caché de grupo de conexiones en frío):

  1. El usuario de la aplicación A solicita una conexión a la base de datos
  2. El grupo de conexiones inicia el hilo de conexión 1 a la base de datos
  3. El usuario de la aplicación B solicita una conexión a la base de datos
  4. El grupo de conexiones inicia el hilo de conexión 2 a la base de datos
  5. El usuario de la aplicación A cierra su conexión ... al grupo de conexiones
  6. El usuario de la aplicación C solicita una conexión a la base de datos
  7. Problemas de agrupación de conexiones sp_reset_connectionen el subproceso 1
  8. El grupo de conexiones asigna el subproceso 1 al usuario de la aplicación C

Esto es una simplificación excesiva, pero los puntos más destacados incluyen:

  • La conexión permanecerá abierta entre el grupo de subprocesos del grupo de conexiones y la base de datos hasta que la base de datos o el grupo de conexiones cierre la conexión por la fuerza
  • La conexión permanece abierta con el contexto de ejecución de las últimas sesiones hasta que ese subproceso sea reutilizado por otro usuario, momento en el que sp_reset_connectionse llama.

Aquí está el material de referencia que solía llegar a estas conclusiones.

Agrupación de conexiones para DBA de SQL Server

El caso de la transacción huérfana

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.