実行に時間がかかるsp_reset_connectionの考えられる原因は何ですか？

sp_reset_connectionSQL Server Profilerで表示すると、システムストアドプロシージャの実行に数ミリ秒以上かかるのはなぜですか？

SQL Serverプロファイラーを使用して運用システムから簡単なトレースを取得し、SqlNexusを使用してそれを分析しました。SqlNexusは、sp_reset_connectionの累積期間が最も長く、トレース全体の33％であることを示しています。観測された期間は0〜7秒（12〜6,833,270マイクロ秒）の範囲ですが、平均は0.956秒です。

プールされた接続が再利用されるときにsp_reset_connectionが呼び出されていることを理解しています。これは無関係なトレースが原因で発生する可能性があるという提案を見ましたが、そうではないようです。

私はsprocが呼び出されたときにサーバーが何をしているかを読みましたが、この場合問題があるとは思いません-コードは、開いたトランザクションやクリーンアップする必要がある巨大な一時テーブルを残していません。

また、https：//serverfault.com/questions/199974/sp-reset-connection-taking-a-long-time-to-runも確認しましたが、役に立ちませんでした。

編集（2013-12-23）： すべてのケースで、読み取りと書き込みは0で、CPUはほぼ常に0です（ゼロ以外のCPUのインスタンスは2つだけで、どちらも16msです）。

sql-server sql-server-2008

— 総合的な開発者
ソース

そのイベントの読み取りと書き込みにはどのような値が表示されますか？

— マーティン・スミス

実行するクエリの種類に関する詳細情報を提供できますか。長くて複雑なトランザクション、XML処理、一時テーブルなど、特に興味深い詳細はありますか？

— エドワードドートランド2013

@Martinの読み取りと書き込みは0です。質問を更新しました。（週末はデータにアクセスできませんでした。）

— Holistic Developer

@EdwardDortlandほとんどのクエリは、明示的なトランザクションや一時テーブルの使用なしで、かなり単純な選択と更新です。実際、通常これらの接続で実行される実際のクエリはかなり高速です-ほんの数ミリ秒。

— Holistic Developer

@HolisticDeveloper-開いているトランザクションを終了する実験を行ったところ、ゼロ以外の読み取りと書き込みが見られたので、そのように見えないことに同意しました。この状況は多かれ少なかれ永続的ですか？もしそうなら、私は、拡張イベントトレースキャプチャを実行したいRPC:Starting、RPC:Completedその後、種類がのspidがその時間の間に発生している待つかを確認するために、データに目を通す短期間の種類を待ちます。

— マーティン・スミス

回答:

最後に、より詳細な回答を書く時間がありました。

単純な手順のsp_reset_connection実行に時間がかかるなど、主に3つの理由があります。

CPUリソースを待機しています
あなたはどこかでロックでブロックされています（おそらくDMLまたは競合するトランザクションの結果として）
ネットワークが遅く、結果をクライアントに返すのに長い時間がかかる

Ad 1） CPUリソースを待機している場合、これはシグナル待機として表示されます。これが問題であるかどうかを診断する方法についての質問に対する私のコメントを参照してください

広告2）ロックを待機している場合、これは、の2つのスナップショットを比較することで最もよく診断されsys.dm_os_wait_statsます。これを行う方法については、この記事を参照してください。

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

LCK_ [Something]の待機時間が長い場合は、クエリsys.dm_tran_locksを実行して、ロックされているオブジェクトを追跡します。あなたの場合、なんらかの形のSCH- [Something]>ロックがブロックしているのがわかると思います。

Ad 3）最初にステップ2でOLEDBとASYNC_NETWORK_IOを待機するためにネットワークの問題を診断する最も簡単な方法（ネットワークを長時間待機している場合は、そのうちの1つが表示されます）。これらの待機時間がxperf -on latency長い場合は、またはnetmonやWiresharkなどのネットワーク監視プログラムを使用して、待ち時間を確認します。ネットワークが低速に見える場合、これは、呼び出し元のアプリケーションサーバーがリサイクルされている接続に十分な速度で応答していないことが原因である可能性もあります。

— トーマス・ケイザー
ソース

私はまだ問題が再発するのを見ていません。そのため、この時点では、提供された回答を使用してさらに診断することはできません。ただし、SQL Serverのパフォーマンスの専門家としてのあなたの評判に基づく回答を受け入れます。

— ホリスティックデベロッパー

この問題に関連している可能性のあるバグのKB記事を見つけました。[ FIX] SQL Server（KB 2926217）でデータベースロックアクティビティが増加すると、パフォーマンスの問題が発生します。説明されている症状の1つは、sp_reset_connection完了するまでに長い時間がかかる可能性があることです。修正プログラムは、次の更新プログラムに含まれています。

SQL Server 2008 SP3用の累積的な更新プログラム17
SQL Server 2008 R2 SP2の累積的な更新13
SQL Server 2012 SP1用の累積的な更新9
SQL Server 2014の累積的な更新1

この動作が確認されたサーバーは、累積的な更新5を適用したSQL Server 2008 SP3を実行していたため、このバグが発生した可能性があります。私はまだ累積的な更新を試していません（問題が常に再発するわけではありません）ので、それがそれを修正するかどうかを確認できません。しかし、誰かが同じ症状を持っている場合に備えて、情報を提供したいと思いました。

— 総合的な開発者
ソース