33

現在、ASP.net 2.0 アプリケーションでいくつかの GUI テストを行っています。RDBMS は SQL Server 2005 です。ホストは Win Server 2003 / IIS 6.0 です。

コードを公開していない外部企業によってプログラムされたため、アプリケーションのソース コードはありません。

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

最終的には .Net ガベージ コレクターによって閉じられると思いますが、それにはしばらく時間がかかります。

SQL Server Management Studio を持っていますが、アクティビティ モニターから、データベースでかなりの数の接続が開かれていることがわかります。

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

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

  2. この種の問題を追跡するのに役立つパフォーマンス カウンターまたはその他の種類のツールの使用方法を学べる優れたオンライン/紙のリソースを知っている人はいますか?

  3. パフォーマンス カウンターが最適なソリューションである場合、監視すべき変数は何ですか?

4

6 に答える 6

63

同様の問題を調査しているこのスレッドを見つけました。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 loginame = '<my_application_login>'
order by last_batch asc

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

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

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

注: 'loginame' のスペル ミス ('n' がありません) はsys.sysprocessesビューにあります。上記のステートメントは正しいです。

loginame nchar(128) ログイン名。

https://docs.microsoft.com/en-us/sql/relational-databases/system-compatibility-views/sys-sysprocesses-transact-sql?view=sql-server-ver15

于 2012-09-14T16:10:19.750 に答える
7

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

于 2010-10-28T19:26:57.333 に答える
2

接続文字列は web.config からいつでも確認できます (主に、接続プールが有効になっている場合、接続制限が有効になっている場合)。

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

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

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

MSDN Magazineにいくつかの記事がありました。また、SOS Debugging ライブラリを使用してアプリケーションのプロセスにアタッチし、手動でチェックすることもできます。

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

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

于 2008-10-17T15:30:51.313 に答える
2

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

それ以外では、ADO.NET 接続プールについて学習することをお勧めします。彼らのコードのバグが本当に疑わしい場合は、MSIL を C# に逆アセンブルするRed Gate の Reflector (現在は無料) を使用してそれを調べることができます。

于 2008-10-17T15:34:13.337 に答える
1

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

于 2011-09-17T02:45:16.777 に答える
1

接続と活動時間を調べることから始めて、接続を開いたままにしているアイテムを見つけることができるかどうかを確認します。

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

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

パフォーマンス カウンターについては、"SQL Server : General Stats" パフォーマンス オブジェクトを調べ始めるとよいでしょう。

于 2008-10-17T15:30:23.203 に答える