1

MS Enterprise Library のデータ アクセス ブロックが SQL への接続をどのように管理するかを理解しようとしています。私が抱えている問題は、(負荷テストからの)安定した負荷の下で、10分間隔でSQLへの接続数が急速に増加することです。これにより、Webサイトからのページ応答時間に顕著なジャンプが発生します.

これは私が実行しているシナリオです:

  • ロード バランサーの背後にある 3 つの Web サーバーに対して実行される Visual Studio ロード テスト ツール
    • ツールは、すべての Web + DB ボックスのパフォーマンス カウンターを完全に可視化します。
  • テストにはそれぞれ約 10 秒かかり、4 つの挿入 (フォームデータ) といくつかの簡単な選択を実行します
  • 60 個のテストが同時に実行されています。テスト全体を通して、負荷の増減はありません。
    • テストは 20 分から 3 時間実行され、一貫した結果が得られます。

そして、これが私たちが目にする問題です:

  • 正確に 10 分ごとに、 SQL の一般的な SQL からのパフォーマンス カウンター: ユーザー接続が増加します - 合計で最大 20 接続 ずつ増加します
    • HTTP ポスト / DB 挿入を実行するページは、最も大きな影響を受けます。他のページは中程度ですが、顕著な上昇を示しています。
    • Web サーバーの CPU/メモリ負荷は影響を受けません
  • この増加は、ページの応答時間の顕著な増加に対応しています。たとえば、平均 0.3 秒から最大 5 秒まで
  • 約 5 分後、多くの接続が解放されますが、Web パフォーマンスには影響しません
  • 最初の上昇から 10 分後に再び発生します。

私が見たもの:

データベース呼び出し:

データベース内のすべての呼び出しは次で始まります。

SqlDatabase database = new SqlDatabase([...]);

そして、必要な出力なしでいずれかの proc を実行します。

return database.ExecuteScalar([...], [...]);

または、using ステートメントにラップして読み取ります。

using (SqlDataReader reader = (SqlDataReader)database.ExecuteReader([...], [...]))
{
    [...]
}

SqlConnection を直接使用することはなく、.Open() または .Close() メソッドもスローされず、例外もスローされません。

データベースの検証:

ログイン/ログアウト イベントに対して SQL プロファイラーを実行し、sp_who2コマンドでスナップショットを作成して、接続の所有者を示しました。後者は、実際に Web サイト (マシン + 資格情報で表示) が接続を保持していることを示しています。

スケジュールされたジョブ (DB または Web サーバー) はなく、Web サーバーからの負荷がない場合、ユーザー接続の負荷は安定しています。

接続プール構成

接続プールの最小サイズと最大サイズは、接続文字列で変更できることを知っています。

例えば:

"データ ソース=[サーバー];初期カタログ=[x];統合セキュリティ=SSPI;最大プール サイズ=75;最小プール サイズ=5; "

フォールバック手段として、最小サイズを ~10 に設定することもできます

デフォルトの最大値が 100 で、デフォルトの最小値が 0 であることを理解しています (ここから)

接続プール (この設定に固有) と SQL からのユーザー接続パフォーマンス カウンターについて考えるのは少し柔軟です。この記事では、これらの接続プールを接続文字列の管理に使用するものとして紹介していますが、これは私が想定しているものとは異なるようです (SQL でそれらを再度開くコストを回避するために、一般的に利用可能な接続のプールを保持します)。

5 分または 10 分に簡単にデフォルト設定されている構成パラメーターをまだ見たことがありません。


だから、どんな助けも大歓迎です。

10 分間のスパイクが負荷の変化や新しいアクティビティの発生のように聞こえることは知っていますが、これらやその他の要因を分離するために非常に努力してきました。下。

ありがとう。

4

1 に答える 1

0

したがって、他のすべての接続がビジーであるときはいつでも、SQLユーザー接続が作成されてプールに追加されることがわかります。したがって、長時間実行されるクエリが発生した場合、またはDBが応答しない場合は、負荷を管理するために拡張することを選択します。

この場合の原因は、たまたまSQLレプリケーションジョブでした(残念ながら、見つかりました...)-そして、ユーザー接続数の変更は単なる症状であり、考えられる原因ではありませんでした。

原因は他の場所にあることが判明しましたが、この(そしておそらく他の)SQLライブラリから接続プールの管理を理解していると感じています。

于 2012-10-19T03:14:09.613 に答える