web-dev-qa-db-fra.com

Nombre maximum de connexions utilisateur

Dans l'édition standard de SQL Server 2012, 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.

enter image description here

sql-serversql-server-2012connections
24
sebeid

Le nombre maximal de connexions pour 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 demander aux développeurs de modifier la chaîne de connexion pour ces applications afin de limiter la taille du pool de connexions et de 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 fait récemment (indépendamment du fait qu'elles soient réellement en cours ) travail), vous pouvez exécuter le code suivant, qui générera une liste de sessions pouvant être supprimées. 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 CV à 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 atom pour tuer une araignée. Elle va tuer l'araignée, mais vous pourriez avoir de plus gros problèmes à la fin de la journée. mentionner qu'il est très difficile de construire une bombe atom, sans parler de l'implémentation du sharding correctement.

31
Max Vernon

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 niez), vous aurez de nombreuses connexions qui restent ouvertes. C'est par conception.

Le regroupement de connexions vise à réduire la surcharge de 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_connection sur le fil 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 de force la connexion
  • La connexion reste ouverte avec le dernier contexte d'exécution des sessions jusqu'à ce que ce thread soit réutilisé par un autre utilisateur, auquel moment sp_reset_connection est 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

12
swasheck