SQL Server ODBC ドライバ、SQL Server OLE DB プロバイダ、または System.Data.SqlClient マネージド プロバイダを使用している場合、対応する API (アプリケーション プログラミング インターフェイス) を使用して、接続プールを無効にできます。プールを無効にすると、使用しているアプリケーションで接続の開設や終了が頻繁に発生する場合、ベースになっている SQL Server ネットワーク ライブラリにかかる負荷が高くなる場合があります。この資料では、特にこのような状況下で調整が必要になることがある、TCP/IP の設定について説明します。
概要
プールを無効にすると、ベースになっている SQL Server ネットワーク ドライバにより、SQL Server を実行しているコンピュータへの新しいソケット接続が頻繁に開設、終了される可能性があります。高い負荷に対処できるように、SQL Server を実行しているオペレーティング システムおよびコンピュータのデフォルトの TCP/IP ソケット設定を変更する必要がある場合があります。
この資料では、TCP/IP プロトコルを使用する場合に SQL Server ネットワーク ライブラリに影響する設定のみを説明しています。プールを無効にすると、名前付きパイプなどのその他の SQL Server プロトコルで負荷に関連する問題が発生する場合もありますが、この資料ではそうした内容については説明しません。この資料は、詳しい知識のあるユーザーのみを対象としています。この資料に記載されている内容に不明な点がある場合は、TCP/IP ソケットに関する詳しい書籍を参照することをお勧めします。
マイクロソフトは、SQL Server ドライバでは常にプールを使用することを、強くお勧めします。SQL Server ドライバでは、プールを使用することにより、クライアント側および SQL Server 側の両方で、全体のパフォーマンスが著しく向上します。また、プールを使用することで、SQL Server を実行しているコンピュータへのネットワーク トラフィックが大幅に減少します。たとえば、SQL Server 接続を 20,000 回開いたり閉じたりするサンプル テストでは、プールが有効になっている場合には 160 個の TCP/IP ネットワーク パケットが使用され、ネットワーク上の処理量は合計で 23,520 バイトでした。同じサンプル テストでプールが無効になっている場合、225,129 個の TCP/IP ネットワーク パケットが生成され、ネットワーク上の処理量の合計は 27,209,622 バイトでした。
SQL Server ネットワーク ライブラリでこれらの負荷に関連する TCP/IP ソケットの問題が発生した場合、SQL Server を実行しているコンピュータに接続するときに、以下のいずれかまたは複数のエラー メッセージが表示されることがあります。
SQL Server が存在しないか、アクセスが拒否されました。
タイムアウトが発生しました
一般的なネットワーク エラーです。
また、SQL Server で他の問題が発生している場合にも、上記のエラー メッセージが表示される可能性があります。上記のエラー メッセージが表示される場合の例には、SQL Server を実行しているリモート コンピュータをシャットダウンした場合、SQL Server を実行しているリモート コンピュータが TCP/IP ソケットでの接続待ちをまったく行っていない場合、ネットワーク ケーブルが接続されておらず、SQL Server を実行しているコンピュータへのネットワーク接続が切断されている場合、DNS 解決の問題が発生している場合などがあります。基本的に、クライアントが SQL Server を実行しているコンピュータに TCP/IP ソケットを開けない原因となるものは、すべてエラー メッセージが表示される原因にもなります。ただし、負荷に関連するソケットの問題では、負荷の増減に従って、断続的に問題が発生します。コンピュータが数時間エラーなしで実行された後、エラーが 1、2 回発生し、その後数時間エラーなしで実行される場合があります。また、この問題が発生している場合、SQL Server への一般的な接続は最初は正常に機能し、次は失敗し、その次は再度正常に機能します。つまり、負荷に関連するソケットの問題は通常、断続的に発生しますが、SQL Server での本当のネットワーク接続の問題は、通常は断続的に発生することはありません。
SQL Server TCP/IP プロトコルを使用時にプールが無効になっている場合、通常は負荷に関連する次の 2 つの主要な問題が発生します。クライアント コンピュータで匿名ポートが不足することや、SQL Server を実行しているコンピュータでデフォルトの WinsockListenBacklog 設定を超過することがあります。
匿名ポートについての関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
319502 [PRB] IMAP 接続の制限を上げた後、匿名ポート経由で接続するとエラー メッセージ "WSAEADDRESSINUSE" が表示される
MaxUserPort 設定および TcpTimedWaitDelay 設定の調整
MaxUserPort および TcpTimedWaitDelay の各設定は、SQL Server を実行していて、接続プールを使用していないリモート コンピュータへの接続を頻繁に開いたり閉じたりするクライアント コンピュータのみに適用できます。たとえば、SQL Server を実行していて、プールが無効な状態で TCP/IP プロトコルを使用しているリモート コンピュータへの接続を頻繁に開いたり閉じたりしている、インターネット インフォメーション サービス (IIS) サーバーで、多数の受信 HTTP 要求を処理している場合には、これらの設定が有効です。プールが有効な場合は、MaxUserPort および TcpTimedWaitDelay の各設定を調整する必要はありません。
TCP/IP プロトコルを使用して SQL Server を実行しているコンピュータへの接続を開くと、ベースになっている SQL Server ネットワーク ライブラリにより SQL Server を実行しているコンピュータへの TCP/IP ソケットが開かれます。このソケットが開かれると、SQL Server ネットワーク ライブラリでは SO_REUSEADDR TCP/IP ソケット オプションが有効になりません。SO_REUSEADDR ソケット設定に関する詳細については、MSDN (Microsoft Developer Network) の「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 状態になっているソケットがタイムアウトするまでは接続できません。
クライアント側では、プールが無効になっている場合、文書番号 319502 の資料に記載されている 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 を実行しているコンピュータで設定しても効果がありません。
WinsockListenBacklog 設定の調整
この SQL サーバー固有のレジストリ設定の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
154628
[SQL]INF: 複数の TCP/IP 接続要求でエラー 17832 が記録される
SQL Server では、WinsockListenBacklog のデフォルトの設定値は 5 です。つまり、SQL Server を実行しているコンピュータで TCP/IP プロトコルをリッスンするスレッドをセットアップすると、SQL Server を実行しているコンピュータにより、待機している Winsock API のバックログ パラメータに値 5 が渡されます。バックログの設定は、リスナに対する保留中の接続キューの最大長です。このキュー長を超えると、SQL Server を実行しているコンピュータに TCP/IP ソケット接続を追加しようとしても、すぐに ACK+RESET パケットで拒否されます。
バックログ設定は次のように機能します。任意のサービスが受信 TCP/IP ソケット要求に対して待機していると仮定します。バックログの値を 5 に設定していて、多くのソケット接続要求を連続して受信する場合、サービスは受信するのと同じ速さでは受信要求に対して応答できない場合があります。この時点では、TCP/IP ソケット層では受信した要求をバックログ キューに挿入して、サービスが後でこのキューから要求を取り出して、受信したソケット接続要求を処理できるようにします。キューがいっぱいになるとすぐに、TCP/IP ソケット層では、それ以降に受信したソケット要求に対して ACK+RESET パケットをクライアントに送信し、ソケット要求を拒否します。バックログ キューのサイズを大きくすると、要求が拒否されるようになるまで、TCP/IP ソケット層でキューに入れられる保留中のソケット接続要求数が増加します。
WinsockListenBacklog 設定は SQL Server に固有の設定です。SQL Server では SQL Server サービスが最初に開始されるときに、このレジストリ設定の読み取りを試行します。この設定が存在しない場合、デフォルト値の 5 が使用されます。このレジストリ設定が存在する場合、TCP/IP ソケットのリッスン スレッドが SQL Server 内部でセットアップされる際に、待機している WinSock API が呼び出されると、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 で実行されている標準のコンピュータであることがわかります。また、Acknowledgement field significant フラグおよび Reset the connection フラグが設定されていることに注意してください。ネットワーク モニタ トレースのフィルタ処理に関する詳しい知識がある場合、TCP フラグの値を 16 進数の 0x14 でフィルタ処理することにより、ネットワーク モニタ トレースで ACK+RESET パケットのみを参照できます。
SQL Server を実行しているコンピュータがまったく稼動していない場合、または、SQL Server を実行しているコンピュータが TCP/IP プロトコルをリッスンしていない場合にも、同様の ACK+RESET パケットが表示されます。このため、ACK+RESET パケットがあるだけでは、この問題が発生していることは断定できません。WinsockListenBacklog の設定が低すぎると、同じタイムフレーム内に、確認応答パケットを受信する接続や、ACK+RESET パケットをすぐに受信する接続が存在することになります。
非常にまれな場合ですが、クライアント コンピュータでプールが有効になっていても、この設定の調整が必要な場合があります。たとえば、多数のクライアント コンピュータが、SQL Server を実行している単一のコンピュータと通信している場合、プールが有効になっていても、ある時点で多数の受信接続が同時に試行される場合があります。
注 : WinsockListenBacklog 設定を調整する場合、この設定を有効にするために Windows を再起動する必要はありません。設定を有効にするためには SQL Server サービスを停止し、再起動します。WinsockListenBacklog レジストリ設定は、SQL Server を実行しているコンピュータのみに対する設定です。SQL Server と通信するクライアント コンピュータには影響はありません。
