Quelles sont les causes possibles de l'exécution longue de sp_reset_connection?

Pourquoi la sp_reset_connectionprocédure stockée système prendrait-elle plus de quelques millisecondes à s'exécuter, telle que vue via SQL Server Profiler?

J'ai pris une trace simple d'un système de production à l'aide de SQL Server Profiler, puis j'ai utilisé SqlNexus pour l'analyser. SqlNexus indique que sp_reset_connection a la durée cumulée la plus élevée - 33% de la trace globale. La durée observée varie de 0 à 7 secondes (12 à 6 833 270 microsecondes) mais se situe en moyenne à 0,956 s.

Je comprends que sp_reset_connection est appelé lorsqu'une connexion en pool est réutilisée. J'ai vu une suggestion que cela peut se produire en raison de traces étrangères , mais cela ne semble pas être le cas.

J'ai lu ce que fait le serveur lorsque le sproc est appelé mais je ne pense pas que cela serait problématique dans ce cas - le code ne laisse pas de transaction ouverte ou d'énormes tables temporaires qui devraient être nettoyées.

J'ai également consulté /server/199974/sp-reset-connection-taking-a-long-time-to-run mais cela n'a pas été utile.

EDIT (2013-12-23): Dans tous les cas, les lectures et les écritures sont égales à 0 et le CPU est presque toujours égal à 0 (seulement deux instances de CPU non nul, toutes deux à 16 ms).

sql-server sql-server-2008

— Développeur holistique
source

Quel type de valeurs voyez-vous pour les lectures et les écritures dans cet événement?

— Martin Smith

Pouvez-vous fournir plus d'informations sur le type de requêtes que vous exécutez. Des détails particulièrement intéressants comme les transactions longues ou complexes, le traitement XML, les tables temporaires?

— Edward Dortland

@Martin lit et écrit est 0. Mise à jour de la question. (N'a pas eu accès aux données pendant le week-end.)

— Développeur holistique

@EdwardDortland la plupart des requêtes sont des sélections et des mises à jour assez simples sans transactions explicites ni utilisation de tables temporaires. En fait, généralement les requêtes réelles exécutées sur ces connexions sont assez rapides - seulement quelques ms.

— Développeur holistique

@HolisticDeveloper - J'ai essayé de laisser une transaction ouverte et je pouvais voir des lectures et des écritures non nulles, alors convenez que cela ne ressemble pas à cela alors. Cette situation est-elle plus ou moins permanente? si oui je courrais une capture de trace des événements étendu RPC:Starting, RPC:Completedet attendre les types pour une courte période puis regardez à travers les données pour voir ce qui attend les types les SPID rencontrent pendant cette période.

— Martin Smith

Réponses:

J'ai enfin eu le temps d'écrire une réponse plus détaillée.

Il existe généralement trois raisons principales pour lesquelles une procédure simple comme celle- sp_reset_connectionci prendra beaucoup de temps.

Vous attendez des ressources CPU
Vous êtes bloqué sur un verrou quelque part (peut-être à la suite de DML ou d'une transaction concurrente)
Votre réseau est lent et il faut beaucoup de temps pour renvoyer le résultat au client

Annonce 1) Si vous attendez des ressources CPU, cela devrait apparaître lorsque le signal attend. S'il vous plaît voir mon commentaire sur votre question sur la façon de diagnostiquer si c'est le problème

Annonce 2) Si vous attendez un verrou, il est préférable de le diagnostiquer en comparant deux instantanés de sys.dm_os_wait_stats. Voir cet article sur la façon de procéder:

http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Si vous voyez de longues attentes pour LCK_ [Quelque chose], interrogez pour localiser sys.dm_tran_locksles objets qui sont verrouillés. Dans votre cas, je m'attendrais à voir une certaine forme de SCH- [Quelque chose]> verrous vous bloquant.

Annonce 3) Le moyen le plus simple de diagnostiquer les problèmes de réseau pour rechercher d'abord OLEDB et ASYNC_NETWORK_IO attend à l'étape 2 (si vous attendez longtemps pour le réseau, l'un d'eux apparaît). Si ces attentes sont élevées, utilisez xperf -on latencyou un programme de surveillance de réseau comme netmon ou wirehark pour vérifier vos latences. Si le réseau semble lent, cela peut également être dû au fait que le serveur d'applications appelant ne répond pas assez rapidement à la connexion en cours de recyclage.

— Thomas Kejser
source

Je n'ai pas encore vu le problème se reproduire, je ne peux donc pas utiliser la réponse fournie pour diagnostiquer davantage à ce stade. Cependant, j'accepte la réponse en fonction de votre réputation en tant qu'expert des performances SQL Server.

— Développeur holistique

Je viens de tomber sur un article de la base de connaissances pour un bogue qui pourrait être lié à ce problème. Dans FIX: des problèmes de performances se produisent lorsque l'activité de verrouillage de la base de données augmente dans SQL Server (KB 2926217), l'un des symptômes décrits est que cela sp_reset_connectionpeut prendre du temps. Le correctif est inclus dans les mises à jour suivantes:

Mise à jour cumulative 17 pour SQL Server 2008 SP3
Mise à jour cumulative 13 pour SQL Server 2008 R2 SP2
Mise à jour cumulative 9 pour SQL Server 2012 SP1
Mise à jour cumulative 1 pour SQL Server 2014

Le serveur sur lequel j'ai observé ce comportement exécutait SQL Server 2008 SP3 avec la mise à jour cumulative 5, il est donc possible qu'il rencontrait ce bogue. Je n'ai pas encore essayé la mise à jour cumulative (le problème ne se reproduit pas tout le temps), je ne peux donc pas vérifier si cela le corrigerait ou non. Cependant, je voulais fournir des informations au cas où quelqu'un aurait les mêmes symptômes.

— Développeur holistique
source