Comment détecter les fuites de connexion SqlServer dans une application ASP.net?

Question

Je suis en train de tester quelques interfaces graphiques sur une application ASP.net 2.0. Le SGBDR est SQL Server 2005. L’hôte est Win Server 2003 / IIS 6.0.

Je n'ai pas le code source de l'application car elle a été programmée par une société externe qui ne le libère pas.

J'ai remarqué que l'application fonctionnait bien au redémarrage d'IIS, mais après quelques tests, après avoir ouvert et fermé mon navigateur pendant quelques heures, l'application commençait à devenir de plus en plus lente. Je me demandais si ce comportement était dû à une mauvaise pratique de connexion des programmeurs: je soupçonne ici une fuite de connexion ouverte sur la base de données.

Je suppose que le ramasse-miettes .Net finira par les fermer mais ... ça peut prendre un moment, non?

J'ai SQL Server Management Studio et le moniteur d'activité indique qu'il y a quelques connexions ouvertes sur la base de données.

De tout ce qui a été dit ci-dessus, voici quelques questions liées à la question principale:

1. Est-il possible de savoir en SQL Server 2005 si les connexions sont ouvert parce qu'ils attendent d'être utilisé dans un pool de connexion ou si ils sont ouverts parce qu'ils sont utilisés par un application?

2. Quelqu'un sait-il de bonnes choses? ressources en ligne / papier où je pouvais apprendre à utiliser la performance des compteurs ou un autre type d'outils pour aider à traquer ce genre de problèmes?

3. Si les compteurs de performance sont les meilleurs solution, quelles sont les variables que je devrait regarder?

Answer 1

Vous pouvez toujours vérifier les chaînes de connexion à partir de web.config (principalement si le regroupement de connexions est activé, si une limite de connexion est activée).

De même, si vous utilisez IIS 6, vous pouvez configurer votre application Web pour qu'elle utilise un pool d'applications distinct, ainsi que d'autres options pour le recyclage de la mémoire et des processus.

À propos des compteurs de performance, vous pouvez vérifier la durée d'exécution du garbage collector, quantité de mémoire utilisée par l'application, etc.

Si vous avez accès au serveur SQL, vous pouvez surveiller les connexions établies à partir de votre application (des compteurs de performance sont définis pour chaque instance installée de SQL Server).

Certains articles de MSDN Magazine . Vous pouvez également utiliser la bibliothèque SOS Debugging pour vous connecter au processus de l'application et le vérifier manuellement.

Et, si vous ne possédez pas le code source, essayez d’utiliser Reflector pour obtenir les sources de l'application (elles seraient très utiles pour le débogage)

@Une modification ultérieure: vous pouvez vérifier cette question ici également sur stackoverflow.com

Answer 2

Vous avez trouvé ce fil à la recherche d'un problème similaire. Je suis venu avec le SQL suivant comme un bon moyen de déboguer des connexions qui fuient dans SQL Server:

SELECT S.spid, login_time, last_batch, status, hostname, program_name, cmd,
(
      select text from sys.dm_exec_sql_text(S.sql_handle)
) as last_sql
FROM sys.sysprocesses S
where dbid > 0
and DB_NAME(dbid) = '<my_database_name>'
and loginname = '<my_application_login>'
order by last_batch asc

Cela vous donne toutes les connexions ouvertes sur une base de données et un nom de connexion particuliers, avec le dernier SQL exécuté sur cette connexion , triés par l'heure à laquelle ce SQL a été exécuté.

En raison du regroupement de connexions, vous ne pouvez pas simplement compter sur le fait qu'il existe de nombreuses connexions pour vous informer que vous avez une fuite de connexion, car le regroupement de connexions conservera les connexions même si elles sont correctement fermées. code. Cependant, si vous avez une fuite de connexion, vous constaterez que certaines connexions deviennent «gelées» - elles apparaîtront dans la requête ci-dessus et l'horodatage de «last_batch» ne changera jamais. Les autres connexions resteront également présentes, mais chaque fois qu'un nouveau SQL sera exécuté, l'horodatage «last_batch» sera mis à jour. L'effet est donc que les connexions gelées vont flotter en haut de cette requête.

Si vous avez le code source de l'application en question, le fait que cela vous donne le dernier code SQL exécuté sur la connexion orpheline est très utile pour le débogage.

Answer 3

J'ai fait face à ce problème et trouvé SQL Server Profiler comme étant un excellent outil. J'ai surveillé le site au cours d'une courte série de tests et constaté que de nombreuses connexions (sp_who) étaient en cours de création et qu'elles n'étaient pas réutilisées par Connection Pool. Server Profiler, puis vérifiez si tous les appels à SP effectués à partir de code ont été suivis d'un "sp_reset_connection". appel. Si l’appel n’est pas là avant le début d’un nouveau lot, il ne manque que la première connexion.

Answer 4

La référence MSDN sur ( compteurs de performance ADO.NET ) est assez clair sur ce que vous pouvez rechercher lors du profilage de l'application. Vous pouvez surveiller les compteurs à l'aide de la perfmon application intégrée à Windows.

En dehors de cela, je vous conseillerais de vous familiariser avec le pooling de connexions ADO.NET. Si vous suspectez réellement un bug dans leur code, vous pouvez le consulter à l'aide de Reflector de Red Gate. (gratuit pour l'instant) qui désassemble le MSIL en C #.

Answer 5

Je commencerais par examiner les connexions et les heures d'activité, et de voir si vous pouvez trouver des éléments qui maintiennent les connexions ouvertes.

Je dirais que si la solution consiste à redémarrer IIS, vous pouvez également consulter l'utilisation de la mémoire de l'application pour voir s'il existe une fuite de mémoire ou quelque chose qui provoque réellement une augmentation de son empreinte.

Si les connexions ouvertes posaient problème, dans le moniteur d'activité, vous verriez un TRÈS grand nombre de connexions sans activité.

Pour les compteurs de performance, vous pouvez commencer par consulter l'onglet "SQL Server: Statistiques générales". objet de performance.

Answer 6

Todd Denlinger a écrit une classe fantastique http://www.codeproject.com/KB/ database / connectionmonitor.aspx qui surveille les connexions Sql Server et signale celles qui n'ont pas été correctement éliminées dans un délai donné. Reliez-le à votre site et il vous avertira en cas de fuite.