概要
SQL Server ODBC ドライバー、SQL Server OLE DB プロバイダー、または System.Data.SqlClient マネージド プロバイダーを使用する場合は、それぞれのアプリケーション プログラミング インターフェイス (API) を使用して接続プールを無効にすることができます。 プールを無効にすると、アプリケーションが頻繁に接続を開いて閉じると、基になるSQL Serverネットワーク ライブラリの負荷が増加する可能性があります。 この記事では、これらの条件下で調整する必要がある特定の TCP/IP 設定について説明します。
追加情報
プールをオフにすると、基になるSQL Serverネットワーク ドライバーが、SQL Serverを実行しているコンピューターへの新しいソケット接続を迅速に開いて閉じる可能性があります。 オペレーティング システムと実行されているコンピューターの既定の TCP/IP ソケット設定を変更SQL Server、より高いストレス レベルに対処する必要がある場合があります。
この記事では、TCP/IP プロトコルを使用する場合にのみ、SQL Server ネットワーク ライブラリに影響する設定について説明します。 プールをオフにすると、名前付きパイプなどの他のSQL Server プロトコルでストレス関連の問題が発生する可能性もありますが、この記事ではこのトピックについて説明しません。 この記事は上級ユーザーのみを対象としています。 この記事のトピックを理解していない場合は、TCP/IP ソケットに関する適切な書籍が表示されることをお勧めします。
Microsoft では、SQL Server ドライバーで常にプールを使用することを強くお勧めします。 プールを使用すると、SQL Server ドライバーを使用する場合、クライアント側とSQL Server側の両方で全体的なパフォーマンスが大幅に向上します。 プールを使用すると、SQL Serverを実行しているコンピューターへのネットワーク トラフィックも大幅に削減されます。 たとえば、20,000 SQL Server接続を使用したサンプル テストでは、プールが有効になっている状態で開き、閉じ、合計 23,520 バイトのネットワーク アクティビティで約 160 TCP/IP ネットワーク パケットを使用しました。 プールが無効になっている場合、同じサンプル テストで 225,129 TCP/IP ネットワーク パケットが生成され、合計 27,209,622 バイトのネットワーク アクティビティが生成されました。
SQL Server ネットワーク ライブラリでこれらのストレス関連の TCP/IP ソケットの問題が発生した場合、SQL Serverを実行しているコンピューターに接続しようとすると、次のエラー メッセージが 1 つ以上表示される可能性があることに注意してください。
注
SQL Serverが存在しないか、アクセスが拒否されました
注
タイムアウトが発生しました
注
一般的なネットワーク エラー
注
TCP プロバイダー: 通常、各ソケット アドレス (プロトコル/ネットワーク アドレス/ポート) の使用は 1 つだけ許可されます。
SQL Serverで他の問題が発生している場合にも、これらの特定のエラー メッセージを受け取ることができます。たとえば、SQL Serverを実行しているリモート コンピューターがシャットダウンされている場合、SQL Server実行中のリモート コンピューターが TCP/IP ソケットをまったくリッスンしていない場合、これらのエラー メッセージを受け取る場合があります(実行中のコンピューターへのネットワーク接続の場合)。ネットワーク ケーブルが引き出されているか、DNS 解決の問題が発生している場合は、SQL Serverが壊れています。 基本的に、クライアントが実行中のコンピューターに TCP/IP ソケットを開けSQL Server失敗する原因となる可能性のあるものも、エラー メッセージを引き起こす可能性があります。 ただし、ストレス関連のソケットの問題では、ストレスが上昇および低下すると、問題が断続的に発生します。 コンピューターは何時間もエラーなしで実行される場合があります。その後、エラーは 1 回または 2 回発生し、コンピューターはエラーなしでさらに数時間実行されます。 また、この問題が発生した場合、SQL Serverへの一般的な接続は 1 つの瞬間に機能し、次の接続は失敗し、次の瞬間にもう一度動作します。 つまり、通常、ストレス関連のソケットの問題は散発的に発生しますが、SQL Serverに関する実際のネットワーク接続の問題は通常、散発的には発生しません。
通常、SQL Server TCP/IP プロトコルを使用しているときにプールを無効にすると、2 つの主なストレス関連の問題が発生します。クライアント コンピューターで匿名ポートが不足している場合や、SQL Serverを実行しているコンピューターの既定の WinsockListenBacklog 設定を超える可能性があります。
匿名ポートの詳細については、以下の記事番号をクリックして、Microsoft サポート技術情報の記事を表示してください。
319502 PRB: IMAP 接続制限を増やした後に匿名ポートを介して接続しようとすると、"WSAEADDRESSINUSE" エラー メッセージが表示される
MaxUserPort と TcpTimedWaitDelay の設定を調整する
MaxUserPort と TcpTimedWaitDelay の設定は、SQL Serverを実行していて、接続プールを使用していないリモート コンピューターへの接続を迅速に開いたり閉じたりしているクライアント コンピューターにのみ適用されることに注意してください。 たとえば、これらの設定は、多数の受信 HTTP 要求を処理しているインターネット インフォメーション サービス (IIS) サーバーで適用され、SQL Serverを実行しており、プールが無効になっている TCP/IP プロトコルを使用しているリモート コンピューターへの接続を開いたり閉じたりしています。 プールが有効になっている場合は、MaxUserPort と TcpTimedWaitDelay の設定を調整する必要はありません。
TCP/IP プロトコルを使用して、SQL Serverを実行しているコンピューターへの接続を開くと、基になるSQL Server ネットワーク ライブラリによって、SQL Serverを実行しているコンピューターに TCP/IP ソケットが開きます。 このソケットを開くと、SQL Server ネットワーク ライブラリでは、SO_REUSEADDR TCP/IP ソケット オプションは有効になりません。 SO_REUSEADDR ソケット設定の詳細については、Microsoft Developer Network (MSDN) の「Setsockopt」トピックを参照してください。
SQL Server ネットワーク ライブラリでは、セキュリティ上の理由から、SO_REUSEADDR TCP/IP ソケット オプションが特に有効にならないことに注意してください。 SO_REUSEADDRが有効になっている場合、悪意のあるユーザーはクライアント ポートを乗っ取ってSQL Serverし、クライアントが提供する資格情報を使用して、SQL Serverを実行しているコンピューターにアクセスできます。 既定では、SQL Server ネットワーク ライブラリでは SO_REUSEADDR ソケット オプションが有効にならないため、クライアント側のSQL Server ネットワーク ライブラリを介してソケットを開いて閉じるたびに、ソケットは 4 分間TIME_WAIT状態になります。 プールが無効になっている TCP/IP 経由のSQL Server接続を迅速に開いたり閉じたりしている場合は、TCP/IP ソケットを迅速に開いたり閉じたりします。 つまり、各SQL Server接続には 1 つの TCP/IP ソケットがあります。 4 分以内に 4,000 ソケットを迅速に開いて閉じると、クライアント匿名ポートの既定の最大設定に達し、既存のTIME_WAIT ソケットセットがタイムアウトするまで、新しいソケット接続試行は失敗します。
クライアント側では、プールを無効にしたときに、Q319502で説明されている MaxUserPort と TcpTimedWaitDelay の設定を増やす必要がある場合があります。 これらの値の設定は、クライアント側で行われるSQL Server接続の開閉の数によって決まります。 クライアント コンピューターの Netstat ツールを使用して、TIME_WAIT状態のクライアント ポートの数を調べることができます。 次のように -n フラグを指定して Netstat ツールを実行し、クライアント ソケットの数を、TIME_WAIT状態のSQL Server IP アドレスにカウントします。 この例では、SQL Server実行されているリモート コンピューターの IP アドレスは 10.10.10.20、クライアント コンピューターの IP アドレスは 10.10.10.10、確立された 3 つの接続と 2 つの接続はTIME_WAIT状態です。
C:\>netstat -n
Active Connections
Proto Local Address Foreign Address State
TCP 10.10.10.10:2000 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2001 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2002 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2003 10.10.10.20:1433 TIME_WAIT
TCP 10.10.10.10:2004 10.10.10.20:1433 TIME_WAIT
netstat -n を実行し、SQL Server実行されているターゲット コンピューターの IP アドレスへの 4,000 近くの接続がTIME_WAIT状態であることがわかります。両方とも、既定の MaxUserPort 設定を増やし、TcpTimedWaitDelay 設定を減らして、クライアントの匿名ポートが不足しないようにすることができます。 たとえば、MaxUserPort 設定を 20000 に設定し、TcpTimedWaitDelay 設定を 30 に設定できます。 TcpTimedWaitDelay の設定が低い場合、ソケットはTIME_WAIT状態で待機する時間が短くなります。 MaxUserPort の設定が高いほど、TIME_WAIT状態のソケットを増やすことができます。
MaxUserPort または TcpTimedWaitDelay 設定を調整する場合は、新しい設定を有効にするために Microsoft Windows を再起動する必要があることに注意してください。 MaxUserPort と TcpTimedWaitDelay の設定は、TCP/IP ソケット経由でSQL Serverを実行しているコンピューターと通信している任意のクライアント コンピューター用です。 これらの設定は、SQL Serverを実行しているローカル コンピューターにローカル TCP/IP ソケット接続を行わない限り、SQL Serverを実行しているコンピューターで設定されている場合は影響しません。
注 MaxUserPort 設定を調整する場合は、SQL Server ブラウザー サービスで使用するためにポート 1434 を予約することをお勧めします (sqlbrowser.exe)。 この手順を実行する方法の関連情報を参照するには、以下のサポート技術情報番号をクリックしてください。
812873 2003 または Windows 2000 Server を実行しているコンピューターで一時的なポートの範囲Windows Server予約する方法
WinsockListenBacklog 設定を調整する
このSQL Server固有のレジストリ設定の詳細については、以下の記事番号をクリックして、Microsoft サポート技術情報の記事を参照してください。
154628 INF: 複数の TCP\IP 接続要求を含む SQL ログ 17832
SQL Server ネットワーク ライブラリが TCP/IP ソケットでリッスンすると、SQL Server ネットワーク ライブラリはリッスン Winsock API を使用します。 リッスン API の 2 番目のパラメーターは、ソケットで許可されるバックログです。 このバックログは、リスナーの保留中の接続のキューの最大長を表します。 キューの長さがこの最大長を超えると、SQL Server ネットワーク ライブラリは、より多くの TCP/IP ソケット接続試行を直ちに拒否します。 さらに、SQL Server ネットワーク ライブラリは ACK+RESET パケットを送信します。
SQL Server 2000 では、既定のリッスン バックログ設定 5 が使用されます。 つまり、SQL Serverを実行しているコンピューターは、リッスン API がSQL Serverを実行しているコンピューターで TCP/IP プロトコルリッスン スレッドを設定するときに、リッスン Winsock API のバックログ パラメーターに値 5 を渡します。 WinsockListenBacklog レジストリ キーを調整して、このパラメーターに渡す別の値を指定できます。 2005 年SQL Server以降、ネットワーク ライブラリは SOMAXCONN の値をバックログ設定としてリッスン API に渡します。 SOMAXCONN を使用すると、Winsock プロバイダーはこの設定に対して最大妥当な値を設定できます。 そのため、winsockListenBacklog レジストリ キーは、SQL Server 2005 では使用されなくなったか、必要ありません。
バックログ設定は次のように機能します。任意のサービスが受信 TCP/IP ソケット要求をリッスンするとします。 バックログ設定を 5 に設定し、多数のソケット接続要求が継続的にストリーミングされている場合、サービスは受信要求に応答できない可能性があります。 この時点で、TCP/IP ソケット層は、これらの受信要求をバックログ キューにキューに入れ、後でこのキューから要求をプルして、受信ソケット接続要求を処理できます。 キューがいっぱいになると、TCP/IP ソケット層は、ACK+RESET パケットをクライアントに送信することによって、追加のソケット要求をすぐに拒否します。 バックログ・キュー・サイズを大きくすると、要求が拒否される前に TCP/IP ソケット層がキューに入る保留中のソケット接続要求の数が増加します。
WinsockListenBacklog 設定はSQL Serverに固有であることに注意してください。 SQL Serverは、SQL Server サービスが最初に開始されたときに、このレジストリ設定の読み取りを試みます。 設定が存在しない場合は、既定値の 5 が使用されます。 レジストリ設定が存在する場合、SQL Serverは設定を読み取り、winSock API listen が TCP/IP ソケットリッスン スレッドがSQL Server内に設定されるときに、指定された値をバックログ設定として使用します。
この問題が発生しているかどうかを判断するには、SQL Serverを実行しているクライアントまたはコンピューターでネットワーク モニター トレースを実行し、ACK+ RESET ですぐに拒否されるソケット接続要求を探します。 ネットワーク モニターで TCP/IP パケットを調べると、この問題が発生したときに次のようなパケットが表示されます。
Frame: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len: 0, seq: 0-0, ack:3409265780, win: 0, src: 1433 dst: 4364
TCP: Source Port = 0x0599
TCP: Destination Port = 0x110C
TCP: Sequence Number = 0 (0x0)
TCP: Acknowledgement Number = 3409265780 (0xCB354474)
TCP: Data Offset = 20 bytes
TCP: Flags = 0x14 : .A.R..
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....1.. = Reset the connection
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 0 (0x0)
TCP: Checksum = 0xF1E7
TCP: Urgent Pointer = 0 (0x0)
ソース ポートは0x599、10 進数では 1433 であることに注意してください。 つまり、パケットは、SQL Serverを実行しており、既定のポート 1433 で実行されている一般的なコンピューターから送信されます。 また、[確認] フィールドが有効であり、[接続フラグのリセット] が設定されていることにも注意してください。 ネットワーク モニター トレースのフィルター処理に慣れている場合は、16 進数を0x14して TCP フラグの値をフィルター処理して、ネットワーク モニター トレースに ACK+ RESET パケットのみを表示できます。
また、SQL Serverを実行しているコンピューターがまったく実行されていない場合や、SQL Server実行中のコンピューターが TCP/IP プロトコルをリッスンしていない場合でも、同様の ACK+ RESET パケットが表示される可能性があるため、ACK+ RESET パケットが表示されても、この問題が発生していることを明確に確認することはできません。 WinsockListenBacklog が低すぎる場合、一部の接続試行では受け入れパケットが受信され、一部の接続は同じ期間内に ACK+RESET パケットをすぐに受信します。
ごくまれに、クライアント コンピューターでプールが有効になっている場合でも、この設定を調整しなければならない場合があることに注意してください。 たとえば、多数のクライアント コンピューターが、SQL Serverを実行している 1 台のコンピューターと通信している場合、プールが有効になっている場合でも、特定の時点で多数の同時接続試行が発生する可能性があります。
注 WinsockListenBacklog 設定を調整した場合、この設定を有効にするために Windows を再起動する必要はありません。 設定を有効にするには、SQL Server サービスを停止して再起動するだけです。 WinsockListenBacklog レジストリ設定は、SQL Serverを実行しているコンピューターに対してのみです。 SQL Serverと通信しているクライアント コンピューターには影響しません。