Dans la plupart des cas, les problèmes de regroupement de connexions sont liés à des «fuites de connexion». Votre application ne ferme probablement pas ses connexions à la base de données correctement et de manière cohérente. Lorsque vous laissez les connexions ouvertes, elles restent bloquées jusqu'à ce que le garbage collector .NET les ferme pour vous en appelant leurFinalize() méthode.
Vous voulez vous assurer que vous fermez vraiment la connexion . Par exemple, le code suivant provoquera une fuite de connexion si le code entre .Openet Closelève une exception:
var connection = new SqlConnection(connectionString);
connection.Open();
// some code
connection.Close();
La bonne façon serait la suivante:
var connection = new SqlConnection(ConnectionString);
try
{
connection.Open();
someCall (connection);
}
finally
{
connection.Close();
}
ou
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
someCall(connection);
}
Lorsque votre fonction renvoie une connexion à partir d'une méthode de classe, assurez-vous de la mettre en cache localement et d'appeler sa Closeméthode. Vous fuierez une connexion en utilisant ce code par exemple:
var command = new OleDbCommand(someUpdateQuery, getConnection());
result = command.ExecuteNonQuery();
connection().Close();
La connexion renvoyée depuis le premier appel à getConnection()n'est pas fermée. Au lieu de fermer votre connexion, cette ligne en crée une nouvelle et essaie de la fermer.
Si vous utilisez SqlDataReaderou a OleDbDataReader, fermez-les. Même si la fermeture de la connexion semble faire l'affaire, faites l'effort supplémentaire de fermer explicitement les objets de votre lecteur de données lorsque vous les utilisez.
Cet article « Pourquoi un dépassement de pool de connexions? » De MSDN / SQL Magazine explique de nombreux détails et suggère quelques stratégies de débogage:
- Exécutez
sp_whoou sp_who2. Ces procédures stockées système renvoient des informations de la sysprocessestable système qui indiquent l'état et les informations sur tous les processus de travail. Généralement, vous verrez un ID de processus serveur (SPID) par connexion. Si vous avez nommé votre connexion en utilisant l'argument Nom de l'application dans la chaîne de connexion, vos connexions de travail seront faciles à trouver.
- Utilisez SQL Server Profiler avec le
TSQL_Replaymodèle SQLProfiler pour tracer les connexions ouvertes. Si vous connaissez Profiler, cette méthode est plus simple que d'interroger en utilisant sp_who.
- Utilisez l'Analyseur de performances pour surveiller les pools et les connexions. Je discute de cette méthode dans un instant.
- Surveillez les compteurs de performances dans le code. Vous pouvez surveiller l'intégrité de votre pool de connexions et le nombre de connexions établies en utilisant des routines pour extraire les compteurs ou en utilisant les nouveaux contrôles .NET PerformanceCounter.