Resumen
Cuando se utiliza el controlador ODBC de SQL Server, el proveedor OLE DB de SQL Server o el proveedor administrado System.Data.SqlClient, puede deshabilitar conexiones utilizando las interfaces de programación de aplicación (API). Al deshabilitar la agrupación de la carga en la biblioteca de red de SQL Server subyacente puede aumentarse si la aplicación con frecuencia se abre y cierra las conexiones. Este artículo describe algunas opciones de configuración de TCP/IP puede que tenga que ajustar en estas condiciones.
Más información
Desactivación de agrupación para hacer que el controlador de red de SQL Server subyacente rápidamente abrir y cerrar nuevas conexiones de socket en el equipo que está ejecutando SQL Server. Tendrá que cambiar la configuración de socket de TCP/IP predeterminada para el sistema operativo y el equipo que está ejecutando SQL Server para tratar con los mayores niveles de estrés.
Tenga en cuenta que este artículo sólo aborda la configuración que afecta a la biblioteca de red de SQL Server cuando se utiliza el protocolo TCP/IP. Desactivar agrupación también puede causar problemas relacionados con el estrés con otros protocolos de SQL Server como canalizaciones con nombre, pero este artículo no describen en este tema. Este artículo es sólo para usuarios avanzados. Si no comprenden los temas de este artículo, Microsoft recomienda que consulte un buen libro sobre sockets TCP/IP.
Tenga en cuenta que Microsoft recomienda que utilice siempre la agrupación con los controladores de SQL Server. Mediante la agrupación en gran medida mejora el rendimiento global en el cliente y el lado de SQL Server cuando utiliza los controladores de SQL Server. Mediante la agrupación considerablemente también reduce el tráfico de red al equipo que está ejecutando SQL Server. Por ejemplo, una prueba de ejemplo que utiliza de SQL Server 20.000 conexión se abre y se cierra con habilitada la agrupación utiliza aproximadamente 160 paquetes de red TCP/IP, para un total de 23.520 bytes de actividad de la red. Con la agrupación deshabilitado, la misma prueba de ejemplo genera paquetes de red TCP/IP 225,129, para un total de bytes de 27,209,622 de actividad de la red.
Tenga en cuenta que cuando vea estos problemas relacionados con el estrés de un socket de TCP/IP con las bibliotecas de red de SQL Server, puede recibir uno o varios de los siguientes mensajes de error cuando intenta conectarse a un equipo que ejecuta SQL Server:
SQL Server no existe o acceso denegado
Tiempo de espera caducado
Error de red general
Proveedor de TCP: Normalmente se permite sólo una utilización de cada dirección de socket (protocolo/red dirección/puerto).
Tenga en cuenta que también puede recibir estos mensajes de error específicos cuando se producen otros problemas con SQL Server; Por ejemplo, puede recibir estos mensajes de error si se apaga el equipo remoto que ejecuta SQL Server, si el equipo remoto que ejecuta SQL Server no está escuchando a sockets TCP/IP, si se interrumpe la conectividad de red al equipo que está ejecutando SQL Server porque se extrae el cable de red, o si tiene problemas con la resolución DNS. Básicamente todo lo que puede ocasionar que el cliente no se pueda abrir un socket TCP/IP en el equipo que ejecuta SQL Server puede causar también los mensajes de error. Sin embargo, con un problema de socket relacionados con el estrés, el problema se produce intermitentemente cuando la carga aumenta o disminuye. El equipo puede ejecutar durante horas sin errores, entonces el error produce una o dos veces y el equipo, a continuación, ejecuta para varias horas más sin errores. Además, cuando surge este problema, generales de conectividad para SQL Server funciona una instantánea, se produce un error la siguiente y vuelve a funcionar la siguiente instantánea. En otras palabras, los problemas relacionados con el estrés socket ocurren esporádicamente, pero problemas de conectividad de red real con SQL Server normalmente no ocurren esporádicamente.
Dos de los problemas principales relacionados con el estrés suelen producen cuando deshabilita la agrupación mientras se utiliza el protocolo TCP/IP de SQL Server: puede quedarse sin puertos anónimos en el equipo cliente o puede exceder el valor de WinsockListenBacklog predeterminado en el equipo que está ejecutando SQL Server.
Para obtener información adicional acerca de los puertos anónimos, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
319502 PRB: 'WSAEADDRESSINUSE' mensaje de Error cuando intenta conectarse a través de un puerto anónimo después de aumentar el límite de conexión de IMAP
Ajustar la configuración de MaxUserPort y TcpTimedWaitDelay
Tenga en cuenta que la configuración de MaxUserPort y TcpTimedWaitDelay es aplicable sólo para un equipo cliente que rápidamente se abrir y cerrar conexiones a un equipo remoto que ejecuta SQL Server y que no utiliza la agrupación de conexiones. Por ejemplo, estas opciones son aplicables en un servidor de servicios de Internet Information Server (IIS) que está dando servicio a un gran número de solicitudes HTTP entrantes y que abre y cierra las conexiones a un equipo remoto que ejecuta SQL Server y que utiliza el protocolo TCP/IP con la agrupación deshabilitado. Si está habilitada la agrupación, no es necesario ajustar la configuración de MaxUserPort y TcpTimedWaitDelay .
Cuando se utiliza el protocolo TCP/IP para abrir una conexión a un equipo que está ejecutando SQL Server, la biblioteca de red de SQL Server subyacente abre un socket TCP/IP en el equipo que está ejecutando SQL Server. Cuando se abre este socket, la biblioteca de red de SQL Server no habilita la opción de socket de TCP/IP SO_REUSEADDR . Para obtener más información acerca de la opción de socket SO_REUSEADDR , vea el tema "Setsockopt" en Microsoft Developer Network (MSDN).
Tenga en cuenta que la biblioteca de red de SQL Server no habilitar específicamente la opción de socket SO_REUSEADDR TCP/IP por motivos de seguridad. Cuando se habilita SO_REUSEADDR , un usuario malintencionado puede apropiarse de un puerto del cliente a SQL Server y las credenciales que proporciona el cliente para tener acceso al equipo que está ejecutando SQL Server. De forma predeterminada, porque la biblioteca de red de SQL Server no habilita la opción de socket SO_REUSEADDR , cada vez que abre y cierra un socket a través de la biblioteca de red de SQL Server en el cliente, el socket entra en un estado TIME_WAIT durante cuatro minutos. Si estás rápidamente de apertura y cierre de las conexiones de SQL Server sobre TCP/IP con la agrupación deshabilitado, se abre rápidamente y cerrar sockets TCP/IP. En otras palabras, cada conexión de SQL Server tiene un socket de TCP/IP. Si se abre y cierran los 4000 sockets en menos de cuatro minutos rápidamente, alcanzará el valor máximo predeterminado para los puertos de cliente anónimo y nuevos intentos de conexión de socket fallan hasta el conjunto de sockets TIME_WAIT existente se agote.
En el lado del cliente, tendrá que aumentar la configuración de MaxUserPort y TcpTimedWaitDelay se trata en Q319502 una vez deshabilitada la agrupación. La configuración de estos valores se determina cuántos conexión de SQL Server se abre y cierra se produce en el cliente. Puede examinar cuántos puertos de cliente están en un estado TIME_WAIT mediante la herramienta Netstat en el equipo cliente. Ejecute la herramienta Netstat con el indicador -n como sigue y contar el número de sockets de cliente a la dirección IP de SQL Server que se encuentran en un estado TIME_WAIT. En este ejemplo, la dirección IP del equipo remoto que ejecuta SQL Server es 10.10.10.20, la dirección IP del equipo cliente es 10.10.10.10 y tres establecido conexiones y dos conexiones están en un estado 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
Si ejecuta netstat - n y comprueba que cerca de 4000 conexiones a la dirección IP dirección del equipo de destino que está ejecutando SQL Server están en un estado TIME_WAIT, puede aumentar el valor de MaxUserPort predeterminado y reducir el valor de TcpTimedWaitDelay para que no se ejecute fuera de los puertos de cliente anónimo. Por ejemplo, puede establecer la configuración de MaxUserPort a 20000 y establezca el valor de TcpTimedWaitDelay en 30. Un valor de TcpTimedWaitDelay inferior significa que los sockets de esperan en el estado TIME_WAIT menos tiempo. Un valor de MaxUserPort mayor significa que puede tener varios sockets en el estado TIME_WAIT.
Tenga en cuenta que si ajusta la configuración de MaxUserPort o TcpTimedWaitDelay , debe reiniciar Microsoft Windows para la nueva configuración surta efecto. La configuración de MaxUserPort y TcpTimedWaitDelay es para cualquier equipo cliente que se está conectando a un equipo que ejecuta SQL Server a través de sockets TCP/IP. Esta configuración no tiene ningún efecto si se establecen en el equipo que ejecuta SQL Server a menos que está realizando conexiones de socket de TCP/IP locales en el equipo local que ejecuta SQL Server.
Nota: Si ajusta la configuración MaxUserPort , recomendamos reservar el puerto 1434 para su uso por el servicio Explorador de SQL Server (sqlbrowser.exe). Para obtener más información acerca de cómo hacerlo, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
812873 cómo reservar un rango de puertos efímeros en un equipo que ejecuta Windows Server 2003 o Windows 2000 Server
Ajustar la configuración de WinsockListenBacklog
Para obtener información adicional acerca de esta configuración del Registro específica de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
154628 INF: SQL registra 17832 con varias solicitudes de conexión TCP/IP
Cuando la biblioteca de red de SQL Server escucha en sockets de TCP/IP, la biblioteca de red de SQL Server utiliza la escucha API Winsock. El segundo parámetro para la escucha API es el trabajo pendiente permitido para el socket. Este registro representa la longitud máxima de la cola de conexiones del agente de escucha pendientes. Cuando la longitud de la cola supera este máximo, la biblioteca de red de SQL Server rechaza inmediatamente más intentos de conexión de socket TCP/IP. Además, la biblioteca de red de SQL Server envía un paquete ACK + RESET.
SQL Server 2000 utiliza una predeterminada escucha configuración del trabajo acumulado de 5. Esto significa que el equipo que está ejecutando SQL Server pasa el valor 5 al parámetro backlog de la escucha API Winsock cuando la API escuchar configura los subprocesos de escucha de protocolo TCP/IP en el equipo que está ejecutando SQL Server. Puede ajustar la clave del registro WinsockListenBacklog para especificar un valor diferente que se pasarán por este parámetro. A partir de SQL Server 2005, la biblioteca de red pasa un valor de SOMAXCONN como la configuración del trabajo acumulado para la escucha API. SOMAXCONN permite al proveedor de Winsock establecer un valor máximo razonable para esta configuración. Por lo tanto, la clave del registro WinsockListenBacklog ya no se utilizan o necesarios en SQL Server 2005.
El trabajo pendiente del establecimiento funciona como sigue: suponga un servicio arbitrario está a la escucha para las solicitudes entrantes de socket de TCP/IP. Si establece la configuración del registro en 5 y continuamente transmite en muchas de las solicitudes de conexión de socket, el servicio no puede responder a las solicitudes entrantes tan rápidas como en la que vienen. En este punto, la capa de sockets de TCP/IP colas estas solicitudes entrantes en la cola de registro y el servicio más adelante puede extraer las solicitudes fuera de esta cola y controlar la solicitud de conexión entrante de socket. Después de que la cola se llena, la capa de sockets de TCP/IP inmediatamente rechaza las solicitudes de socket adicional que vienen en enviando un paquete ACK + RESET al cliente. El aumento de los aumentos de tamaño backlog cola que número de espera de conexión de socket solicitudes que la capa de sockets de TCP/IP pone en cola antes de que se rechazan las solicitudes.
Tenga en cuenta que la configuración de WinsockListenBacklog es específica de SQL Server. SQL Server intenta leer este valor del registro cuando se inicie el servicio SQL Server. Si el valor no existe, se utiliza el valor predeterminado de 5. Si el valor del registro no existe, SQL Server lee la configuración y utiliza el valor proporcionado como el valor de trabajo pendiente cuando escuche la API de WinSock se llama como los subprocesos de escucha de socket de TCP/IP se establecen hasta dentro de SQL Server.
Para determinar si está ejecutando en este problema, puede ejecutar una traza de Monitor de red en el cliente o el equipo que está ejecutando SQL Server y busque las solicitudes de conexión de socket son rechazadas inmediatamente con un ACK + RESET. Si examina los paquetes TCP/IP en Monitor de red, verá un paquete como el siguiente cuando se produzca este problema:
Frame: Base frame propertiesETHERNET: 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)
Observe que el puerto de origen es 0x599 o 1433 en formato decimal. Esto significa que el paquete procede de un equipo típico que ejecuta SQL Server y que se ejecuta en el puerto predeterminado de 1433. Tenga en cuenta que se establecen el campo de confirmación y los indicadores de Restablecer la conexión . Si está familiarizado con el filtrado de una traza de Monitor de red, puede filtrar el valor de Flags TCP por 0 x 14 hexadecimal para ver sólo los paquetes ACK + RESET en la traza de Monitor de red.
Tenga en cuenta que también puede ver los paquetes ACK + RESET similares si el equipo que está ejecutando SQL Server no se ejecuta en absoluto, o si el equipo que está ejecutando SQL Server no está escuchando en el protocolo TCP/IP, para ver los paquetes ACK + RESET no es confirmación definitiva que experimenta este problema. Si la WinsockListenBacklog es demasiado bajo, algunos conexión intentos de reciban paquetes de aceptación y algunas conexiones reciben inmediatamente los paquetes ACK + RESET en la misma franja horaria.
Tenga en cuenta que en casos muy raros, tendrá que ajustar esta configuración, incluso si la agrupación está habilitada en los equipos cliente. Por ejemplo, si muchos equipos cliente están hablando con un único equipo que está ejecutando SQL Server, un gran número de intentos de conexión entrantes simultáneas puede producirse en cualquier momento determinado, incluso si está habilitada la agrupación.
Nota: Si ajusta la configuración de WinsockListenBacklog , no es necesario reiniciar Windows para que esta configuración surta efecto. Simplemente, detenga y reinicie el servicio SQL Server para que la configuración surta efecto. La configuración de registro de WinsockListenBacklog es sólo para el equipo que está ejecutando SQL Server. No tiene ningún efecto en cualquier equipo cliente que se está conectando a SQL Server.
