|
SQLSERVERユーザー接続 パフォーマンスカウンター内のSQLインスタンスの一般統計ユーザー接続はそれに対応します また、パフォーマンスカウンタでTCPv4Connections Established Usedを参照することもできます
SQLSERVERサービスのみを搭載したマシンでは、TCPV4接続の確立とMssqlユーザー接続これら2つのパラメータは基本的に同期されており、以下のテスト内容で接続数と呼ばれています
この接続数は最大並行数制限に似ています。 この制限に達すると、空きCPU、IO、MEMリソースがあってもクエリが応答しなくなります(一部クエリは影響を受けますが、すべてのクエリが影響を受けます)。
TCPV4接続の確立およびMssqlユーザー接続の最大値は以下の要因に依存します
a. 実行文の複雑さは関連しており、文が複雑であればあるほど接続数は小さくなります(この効果は非常に重要)
b. これはリクエストのスレッド同時実行に関連しています。
10のプロセス、各プロセスは5,000スレッドを開いてリクエストします。SELECT getdate()この文は約4000に達した時点ですでに放棄されています(私の理解では、多くのスレッドがリソースを要求していないものの、リクエスト数が多く、それも影響を与えています)。
10のプロセス、各プロセスは1000スレッドを開いてリクエストします。 SELECT getdate()声明は1万件を超えることもあります。
c. スレッドリクエストの頻度に関連しています
各スレッドがクエリを実行して0〜10,000ミリ秒の間一時停止すれば、停止していない場合よりも接続数が少なくなります
d. 試験では、一部の非密閉接続がカウンターの膨張を引き起こすことも判明しましたが、これは議論されませんでした
10プロセス、各プロセスは1000リクエストスレッドを開き、サーバー上の各クエリの後にランダムに0秒から10秒間停止します。テスト結果は以下の通りです:
実行:[システム]から*を選択してください。 [dbo]。 [DBA_alert](このクエリは200行を返し、最大接続数は700で問題が発生します)
接続数が700に達するとエラーが報告され始め、1200に達すると大量のエラーが発生し、1800前後の接続数は停滞し増加しなくなります。 エラーや接続の遅さは多いです
実行:SELECT getdate()刑期(最大接続数は3500で問題が始まります)
接続数が3500に達すると、そのうちいくつかがエラーを報告し始め、最高圧力は約11000に達し、接続数はゆっくりと増加し続けます。 エラーや接続の遅延
結論はこうです:与えられた圧力条件下で、最も簡単に実行できることSELECT getdate() と [system] を実行すると、最大接続数は3500まで可能です。 [dbo]。 [DBA_alert]文では、最大接続数は700までまでです。クエリタイムアウトは、CPU、IO、MEMの各リソースが多数のアイドルリソースを持つ場合に発生します。
本番環境では10×1000スレッドの圧力には達しませんが、SQLはテスト環境よりも複雑になります。
同時運行数ボトルネックはパソコンやサーバーのネットワークカードの帯域幅が原因ではありません
上記のことを証明するために。 私は以下のテストを行いました。大規模な並行性の場合はexec dbo.run2;
ALTERは[dbo]発動します。 [run2]
として
セット・ノーカウント
Get Date()
@i イントを宣言
@i=0
一方@i<1000 この値が1000の場合、最大接続数は約1300、10の場合は通常5000に達するのが一般的です。
開始
[公開]に挿入してください。 [dbo]。 [tb_test]([name]) 値 (newid())
セット @i=@i+1
終わり
行け
変更サイクルの数は戻り結果には影響しません。つまり、ネットワークカードのトラフィックへの圧力は同じですが、一方はすぐにタイムアウトし、もう一方は常にチェックできるため、両側のネットワークカードの帯域幅の影響を排除できます。
最大接続数が停止したときのエラー内容:
netstat-最大接続数が停滞したときの結果(強く確立されている):
最大接続数が停止したときのテストプログラム実行図:
注目すべき点は以下の通りです。エラーやタイムアウトとの関連は均等ではなく、特定のプロセスに集中します。つまり、あるプロセスは常に正常に動作し、もう一方は長期間エラーを報告します(これはプロセスの開始順とは関係なく、私の理解では、一部のプロセスはリソースを持ち、通常通り動作を続けられますが、元のリソース内のスレッド内の他のプロセスはプリエンプトされ、新しいリソースに適用できず、繰り返しエラーを報告し続けます)。上記の図に示すように、2番目と7番目のプロセスは多くのタイムアウトが発生し始め、他のプロセスは動作を続けました。 サーバー上では、クエリが一部のマシンから影響を受けていないか、影響が少ないように見えることがあり、一部のマシンは大きく影響を受けます。
結論:SQLSERVERユーザー接続の上限は一連の条件に関連していますが、ボトルネックの推定と予測は依然として可能です。この上限に達すると、多数のクエリが遅くなりタイムアウトが生じます(ただしCPU、IOなどは問題ありません。 MEM、トラフィックはアイドルリソースがある場合にも発生することがあります。 実際、TCPパラメータを変更するとこの上限が上がり、後で補足を書くかもしれません
| 
掲載地 2014/11/26 15:11:08
|
|
|
|
