Nombre maximum de connexions utilisateur

Dans SQL Server 2012 Standard Edition, je sais que le nombre maximum de connexions utilisateur est de 32 767. Que dois-je faire en tant que DBA si je me dirige vers ce numéro?

Il existe actuellement 30 000 connexions d'utilisateurs, et ce nombre devrait augmenter.

Le nombre maximal de connexions entre les versions et éditions de SQL Server est de 32 767.

Vous pouvez déterminer le nombre de connexions que SQL Server possède actuellement en consultant:

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 le rapport entre les connexions utilisées et inutilisées de la requête ci-dessus est préoccupant, il est probable que le regroupement de connexions est activé par les applications clientes connectées au serveur, et ces connexions ne sont pas utilisées efficacement. Vous souhaiterez peut-être que les développeurs modifient la chaîne de connexion de ces applications pour limiter la taille du pool de connexions et s’assurer qu’ils éliminent correctement les connexions. Si les connexions ne sont pas supprimées correctement, elles resteront ouvertes tant que l'application cliente s'exécutera.

Si vous vous sentez particulièrement enragé et que vous devez vous débarrasser de toutes les connexions qui n'ont rien effectué récemment (indépendamment du fait qu'elles effectuent actuellement un travail), vous pouvez exécuter le code suivant, qui générera une liste de sessions qui peut être tué. Vous devez copier-coller les commandes générées dans une nouvelle fenêtre SSMS pour exécuter réellement les commandes. Je recommanderais également d'avoir votre curriculum vitae à jour au cas où .

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;

Il est possible de mettre à l'échelle le nombre de connexions de manière linéaire au-delà de 32 767 en partageant les données sur plusieurs nœuds SQL Server. Cependant, à mon avis, l'utilisation du sharding comme moyen de contourner la limite du nombre de connexions est similaire à l'utilisation d'une bombe atomique pour tuer une araignée. Il va tuer l'araignée, mais vous ne peut avoir de plus gros problèmes à la fin de la journée. Sans oublier qu'il est assez difficile de construire une bombe atomique, sans parler de mettre en œuvre le sharding correctement.

J'ai rencontré un comportement étrange avec la mise en commun de connexions dans le passé, et votre scénario correspond bien à l'une de ces situations. Si votre application utilise le pool de connexions (et c'est toujours de la spéculation, à ce stade, jusqu'à ce que vous le confirmiez ou le refusiez), vous aurez de nombreuses connexions qui restent ouvertes. C'est par conception.

Le regroupement de connexions vise à réduire les frais généraux liés à la création d'une connexion à une base de données. Prenons, par exemple, un pool de connexions de 3. Pour autant que je sache, le cycle de vie va quelque chose comme ça (à partir d'un cache de pool de connexions froid):

1. L'utilisateur d'application A demande une connexion à la base de données
2. Le pool de connexions démarre le thread de connexion 1 à la base de données
3. L'utilisateur d'application B demande une connexion à la base de données
4. Le pool de connexions démarre le thread de connexion 2 à la base de données
5. L'utilisateur d'application A ferme sa connexion ... au pool de connexions
6. L'utilisateur d'application C demande une connexion à la base de données
7. Problèmes de pool de connexions sp_reset_connectionsur le thread 1
8. Le pool de connexions affecte le thread 1 à l'utilisateur d'application C

Il s'agit d'une simplification excessive, mais les points saillants comprennent:

• La connexion restera ouverte entre le pool de threads du pool de connexions et la base de données jusqu'à ce que la base de données ou le pool de connexions ferme la connexion de force
• La connexion reste ouverte avec le contexte d'exécution des dernières sessions jusqu'à ce que ce thread soit réutilisé par un autre utilisateur, auquel moment il sp_reset_connectionest appelé.

Voici le matériel de référence que j'ai utilisé pour arriver à ces conclusions.

Pool de connexions pour SQL Server DBA

Le cas d'une transaction orpheline