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번 열고 닫는 예제 테스트에서 총 23,520바이트의 네트워크 작업에 대해 약 160개의 TCP/IP 네트워크 소켓을 사용했지만 풀링을 해제한 상태에서는 동일한 예제 테스트가 총 27,209,622바이트의 네트워크 작업에 대해 225,129개의 TCP/IP 네트워크 소켓을 생성했습니다.
SQL Server 네트워크 라이브러리에 이러한 스트레스 관련 TCP/IP 소켓 문제가 나타날 경우 SQL Server를 실행하는 컴퓨터에 연결하려고 하면 다음 오류 메시지 중 하나 이상이 나타날 수 있습니다.
SQL Server가 없거나 액세스가 거부되었습니다.
시간이 초과되었습니다.
일반 네트워크 오류입니다.
SQL Server에 다른 문제가 발생할 때도 이러한 특정 오류 메시지가 나타날 수 있습니다. 예를 들어, SQL Server를 실행하는 원격 컴퓨터가 종료되거나 TCP/IP 소켓을 전혀 수신 대기하지 않는 경우, 네트워크 케이블이 뽑혀서 SQL Server를 실행하는 컴퓨터에 대한 네트워크 연결이 끊어진 경우, DNS 확인 문제가 있는 경우 이러한 오류 메시지가 나타날 수 있습니다. 기본적으로 SQL Server를 실행하는 컴퓨터에 대해 클라이언트가 TCP/IP 소켓을 열 수 없도록 하는 문제는 오류 메시지를 수반할 수 있습니다. 그러나 스트레스 관련 소켓 문제가 있으면 스트레스가 증가하거나 감소함에 따라 문제가 간헐적으로 발생합니다. 컴퓨터가 오류 없이 몇 시간 동안 실행되다가 오류가 한 두 번 발생한 다음 다시 여러 시간 동안 오류 없이 실행될 수 있습니다. 또한 이 문제가 있으면 SQL Server에 대한 일반 연결은 한 인스턴스에서 작동하고 다음 인스턴스에서는 실패하고 그 다음 인스턴스에서는 다시 작동하게 됩니다. 즉, 스트레스 관련 소켓 문제는 대개 산발적으로 발생하지만 SQL Server의 실제 네트워크 연결 문제는 산발적으로 발생하지 않습니다.
SQL Server TCP/IP 프로토콜을 사용하는 동안 풀링을 해제하면 일반적으로 두 가지 주요 스트레스 관련 문제가 발생합니다. 클라이언트 컴퓨터에 익명 포트가 없거나 SQL Server를 실행하는 컴퓨터에서 기본 WinsockListenBacklog 설정을 초과할 수 있습니다.
익명 포트에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
319502 PRB: IMAP 연결 제한을 늘린 후 익명 포트를 통해 연결하려고 하면 "WSAEADDRESSINUSE" 오류 메시지가 나타난다
MaxUserPort 및 TcpTimedWaitDelay 설정 조정
연결 풀링을 사용하지 않고 SQL Server를 실행하는 원격 컴퓨터에 대한 연결을 빠르게 열고 닫는 클라이언트 컴퓨터에 대해서만 MaxUserPort 및 TcpTimedWaitDelay 설정을 적용할 수 있습니다. 예를 들어, 이러한 설정은 많은 수의 들어오는 HTTP 요청을 서비스하고 SQL Server를 실행하는 원격 컴퓨터에 대한 연결을 열고 닫으며 풀링이 해제된 상태에서 TCP/IP 프로토콜을 사용하는 인터넷 정보 서비스(IIS) 서버에 적용할 수 있습니다. 풀링이 설정된 경우에는 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 연결마다 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이며 설정된 연결 세 개와 연결 두 개가 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 Server 관련 레지스트리 설정에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
154628 INF: TCP/IP 연결 요청이 여러 개인 경우 SQL이 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 또는 십진수로 1433입니다. 이것은 SQL Server를 실행하고 기본 포트 1433에서 실행되는 일반 컴퓨터에서 패킷이 오는 것을 의미합니다. 또한 응답 유효 필드 및 연결 재설정 플래그가 설정됩니다. 네트워크 모니터 추적 필터링에 익숙한 경우 0x14 16진수로 TCP 플래그 값을 필터링하여 네트워크 모니터 추적에서 ACK+RESET 패킷만 볼 수 있습니다.
SQL Server를 실행하는 컴퓨터가 전혀 실행되고 있지 않거나 TCP/IP 프로토콜을 수신 대기하고 있지 않은 경우에도 유사한 ACK+RESET 패킷을 볼 수 있으므로 ACK+RESET 패킷이 표시된다고 이 문제가 있는 것으로 확신할 수 없습니다. WinsockListenBacklog가 너무 낮은 경우 일부 연결 시도는 수락 패킷을 수신하는 반면 동시에 일부 연결은 즉시 ACK+RESET 패킷을 수신합니다.
매우 드문 경우에 클라이언트 컴퓨터에 풀링이 설정된 경우에도 이 설정을 조정해야 할 수 있습니다. 예를 들어, 많은 클라이언트 컴퓨터가 SQL Server를 실행하는 단일 컴퓨터와 통신하는 경우 풀링이 설정되어 있어도 동시에 들어오는 많은 연결 시도가 특정 시간에 발생할 수 있습니다.
참고 WinsockListenBacklog 설정을 조정하는 경우 이 설정을 적용하기 위해 Windows를 다시 시작할 필요가 없습니다. 설정을 적용하려면 SQL Server 서비스만 중지했다가 다시 시작하면 됩니다. WinsockListenBacklog 레지스트리 설정은 SQL Server를 실행하는 컴퓨터에만 적용됩니다. SQL Server와 통신하는 클라이언트 컴퓨터에는 영향을 주지 않습니다.
Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.
