web-dev-qa-db-ja.com

ASP.netアプリケーションでSqlServer接続リークを検出する方法は？

現在、ASP.net2.0アプリケーションでいくつかのGUIテストを行っています。 RDBMSはSQLServer2005です。ホストはWinServer 2003/IIS 6.0です。

アプリケーションのソースコードは、コードをリリースしていない外部の会社によってプログラムされたものであるため、私は持っていません。

IISを再起動すると、アプリケーションのパフォーマンスが向上することに気付きましたが、テストを行った後、ブラウザを数時間開いたり閉じたりすると、アプリケーションの速度がどんどん遅くなり始めます。この動作は、プログラマーによる接続のクローズ方法が不適切なためかどうか疑問に思っていました。ここのデータベースでオープン接続のリークが発生しているのではないかと疑っています。

.Netガベージコレクターは最終的にそれらを閉じると思いますが...それは時間がかかる可能性がありますね？

SQL Server Management Studioを使用していますが、アクティビティモニターから、データベースでかなりの数の接続が開かれていることに気付きました。

上記のすべてから、主な質問に関連するいくつかの質問があります：

  1. SQL Server 2005で、接続が接続プールで使用されるのを待っているために開いているかどうか、またはアプリケーションによって使用されているために開いているかどうかを知る方法はありますか？

  2. 誰かが、パフォーマンスカウンターやその他の種類のツールを使用して、この種の問題を追跡する方法を学ぶことができる優れたオンライン/紙のリソースを知っていますか？

  3. パフォーマンスカウンターが最善の解決策である場合、注意すべき変数は何ですか？

asp.netsql-serverconnection-poolingperformancecounterconnection-leaks
31
Diego Tercero

Web.configからいつでも接続文字列を確認できます（主に、接続プールがアクティブになっている場合、接続制限が有効になっている場合）。

また、IIS 6を使用している場合は、別のアプリケーションプールを使用するようにWebアプリケーションを設定し、メモリとプロセスをリサイクルするための他のオプションを設定できます。

パフォーマンスカウンターについては、ガベージコレクターの実行時間、アプリケーションが使用しているメモリの量などを確認できます。

SQL Serverにアクセスできる場合は、アプリケーションからの接続を監視できます（SQL Serverのインストール済みインスタンスごとにパフォーマンスカウンターが定義されています）。

MSDN Magazine にいくつかの記事がありました。また、SOSデバッグライブラリを使用して、アプリケーションのプロセスに接続し、手動で確認することもできます。

また、ソースコードがない場合は、 Reflector を使用してアプリケーションのソースを取得してみてください（デバッグに非常に役立ちます）

@後で編集：これを確認できます 質問 ここstackoverflow.comでも

2
Bogdan Maxim

このスレッドが同様の問題を調査しているのを見つけました。 SQL Serverでリーク接続をデバッグするための良い方法として、次のSQLを思いつきました。

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

これにより、特定のデータベースで開いているすべての接続とログイン、その接続で実行された最後のSQLとともに、そのSQLが実行された時刻でソートされます。

接続プールがあるため、接続がリークしていることを示すために接続がたくさんあるという事実だけに頼ることはできません。接続プールは、コードから正しく閉じられている場合でも接続を維持するためです。ただし、接続リークがある場合は、一部の接続が「フリーズ」していることがわかります。これらは上記のクエリに表示され、「last_batch」タイムスタンプは変更されません。他の接続もハングしますが、新しいSQLが実行されるたびに、「last_batch」タイムスタンプが更新されます。したがって、凍結された接続はこのクエリの先頭にフロートします。

問題のアプリケーションのソースコードがある場合、これにより、孤立した接続で最後に実行されたSQLが得られるという事実は、デバッグに非常に役立ちます。

59
user1617425

この問題に直面し、SQL Server Profilerが優れたツールであることがわかりました。短いテスト実行でサイトを監視し、接続プールで再利用されない接続（sp_who）が多数作成されていることに気付いたので、SQL ServerProfilerを開いて次に、コードから行われたSPへのすべての呼び出しの後に「sp_reset_connection」呼び出しが続くかどうかを確認します。新しいバッチの開始前に呼び出しがない場合は、最初の接続が不足しているだけです。

7
Pablo

（ ADO.NETパフォーマンスカウンター ）に関するMSDNリファレンスは、アプリケーションのプロファイリング時に何を探すことができるかについてかなり明確です。 Windowsに組み込まれている perfmon アプリケーションを使用して、カウンターを監視できます。

それ以外に、ADO.NET接続プールについて学ぶことをお勧めします。コードにバグがあると本当に疑われる場合は、MSILをC＃に分解する Red Gate's Reflector （今のところ無料）を使用してバグを確認できます。

2
Dave

まず、接続とアクティビティ時間を確認し、接続を開いたままにしているアイテムを見つけることができるかどうかを確認します。

解決策がIISを再起動することである場合は、アプリケーションのメモリ使用量を調べて、メモリリークなど、実際にフットプリントが大きくなる原因がないかどうかを確認することもできます。

開いている接続が問題である場合、アクティビティモニターに、アクティビティのない非常に多数の接続が表示されます。

パフォーマンスカウンターについては、「SQL Server：GeneralStats」パフォーマンスオブジェクトを確認することをお勧めします。

1
Mitchel Sellers

Todd Denlingerは素晴らしいクラスを作成しました http://www.codeproject.com/KB/database/connectionmonitor.aspx Sql Server接続を監視し、一定期間内に適切に破棄されなかった接続について報告します。あなたのサイトにそれを配線してください、そしてそれは漏れがあるときあなたに知らせます。

1
Andrew Csontos