web-dev-qa-db-ja.com

SQL Server 2014で15000以上のスリープセッション

CPU使用率は定期的に100％になり、SP_who2を確認すると、約20000セッションが表示され、ほとんどのセッションがスリープしています（CPUも使用しています）。
CPU負荷はスリープセッションに関連していると思います

アプリケーション名はMicrosoft JDBCとして表示されています。

ほとんどのセッションで、last_wait_typeとして「SOS_SCHEDULER_YIELD」が表示されています。 Windows Serverを再起動した後、CPU使用率は低下していますが、セッション数が増加しています。

サーバーには32コアがあります。

アプリケーションチームは、接続管理に「接続プール」を使用していると伝えています。

スリープセッションの数を調査または解決するにはどうすればよいですか？

sql-serversql-server-2014performancecpuperformance-tuning
3
Singh

アプリケーションはおそらく接続をリークしています。彼らが何を意味するのか私にはわかりません

アプリケーションチームは、接続管理に「接続プール」を使用していると伝えています。

しかし、彼らは彼ら自身の接続プーリングシステムを実装しようとしているように聞こえます。

一般に、同じ接続で.open()を呼び出さずに.close()を呼び出した場合、接続リークが発生します。

これは一般的にクライアントの問題であるため、データベース側から実行できる唯一のこと（たまにそれらを強制終了することはできませんが、そうすることはお勧めしません）は、sys.dm_exec_sessionsの情報を使用して見つけることですアプリケーションが接続をリークし、開発者またはベンダーに連絡して、問題のあるコードを検索できるようにします。

たとえば、次のクエリ（ here から取得：

select count(*) as sessions,
     s.Host_name,
     s.Host_process_id,
     s.program_name,
     db_name(s.database_id) as database_name
from sys.dm_exec_sessions s
where is_user_process = 1
group by Host_name, Host_process_id, program_name, database_id
order by count(*) desc;

プロセスごとのホストごとの接続数が表示されます。これは、問題のあるアプリケーションを識別するのに十分なはずです。

また、時間の経過とともにこの情報をログに記録するジョブを作成して、接続が本当に常に増加しているかどうかをグラフにして、実際にリークがあることをアプリケーションチームに「証明」することもできます。

6
Tom V - try topanswers.xyz

アプリケーションチームは、接続管理に「接続プール」を使用していると伝えています。

ここでは、3つのことが起こります。

  • 1つは、彼らが独自のアプリプールを展開し、それが壊れているだけです。新しい接続を配り続けますが、閉じません。
  • 次に、誰かがとても賢く、15000の接続を開いてから使用するようにプールに指示しました。はい、時々人々はとんでもないデフォルト値を立てます。
  • 第三に、接続を適切に閉じません。また、アプリプールには上限が設定されていません。そのため、あたかも存在しないかのように新しい接続を作成し続けます。それらは決して閉じられないため、プールに戻されることはありません。

150000のアイドル接続を持つサイズのサーバー上にアプリプールを配置することが論理的に設定されているわけではありません。

3
TomTom