Descripción de configuración de TCP/IP que es posible que tenga que ajustar cuando la agrupación de conexiones de SQL Server está deshabilitada

Cuando se utiliza el controlador ODBC de SQL Server, el proveedor de OLE DB de SQL Server o el proveedor administrado System.Data.SqlClient, puede deshabilitar la agrupación de conexiones utilizando las interfaces de programación respectivos de la aplicación (API). Cuando deshabilita la agrupación, se puede aumentar la carga en la biblioteca de red SQL Server subyacente si la aplicación abre y cierra las conexiones con frecuencia. Este artículo describe determinados configuración de TCP/IP que puede tener para ajustar estas condiciones.

La desactivación agrupación puede provocar el controlador de red de SQL Server subyacente abrir rápidamente y cerrar nuevas conexiones de socket en el equipo que ejecuta SQL Server. Quizás tenga que cambiar configuración de socket de TCP/IP de predeterminada para el sistema operativo y el equipo que ejecuta SQL Server para tratar los niveles de carga superiores.

Tenga en cuenta que en este artículo sólo se describen opciones que afectan a la biblioteca de red SQL Server cuando se utiliza el protocolo TCP/IP. Desactivar agrupación puede hacer también problemas de carga con otros protocolos de SQL Server, como canalizaciones con nombre, pero este artículo no trata este tema. Este artículo es sólo para usuarios avanzados. Si no entiende los temas de este artículo, Microsoft recomienda que ve un buen libro sobre sockets TCP/IP.

Tenga en cuenta que Microsoft recomienda encarecidamente que utilice siempre la agrupación con los controladores de SQL Server. Mediante la agrupación enormemente mejora el rendimiento general en el cliente y el servidor de SQL cuando utiliza los controladores de SQL Server. Uso de agrupación considerablemente también reduce el tráfico de red al equipo que ejecuta SQL Server. Por ejemplo, una prueba de ejemplo que utiliza 20.000 SQL Server conexión abre y cierra con habilitada la agrupación utiliza aproximadamente 160 paquetes de red TCP/IP, para un total de bytes 23,520 de actividad de red. Con la agrupación deshabilitado, la misma prueba de ejemplo genera 225,129 paquetes de red TCP/IP, para un total de bytes 27,209,622 de actividad de red.

Tenga en cuenta que cuando vea estos problemas de socket de TCP/IP carga relacionados 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: Tenga en cuenta que también puede recibir estos mensajes de error específico cuando se producen otros problemas con SQL Server; por ejemplo, puede recibir estos mensajes de error si el equipo remoto que ejecuta SQL Server se apaga, si el equipo remoto que ejecuta SQL Server no está escuchando a sockets TCP/IP, si se interrumpe la conectividad de red con el equipo que ejecuta SQL Server porque se ha extraído el cable de red, o si están teniendo problemas de resolución de DNS. Básicamente todo lo que puede hacer que el cliente producirá un error al abrir un socket TCP/IP al equipo que ejecuta SQL Server puede causar también los mensajes de error. Sin embargo, con un problema de socket de carga, el problema ocurre intermitentemente como la carga aumenta y se encuentra. El equipo puede ejecutar durante horas sin errores, a continuación el error produce una o dos veces y el equipo, ejecuta para varias horas más sin errores. Además, cuando tiene este problema, general conectividad a SQL Server funciona una instantánea, falla la siguiente y después vuelve a funciona la instantánea siguiente. En otras palabras, problemas relacionados con el estrés socket suelen producen esporádicamente pero problemas de conectividad de red real con SQL Server normalmente no se producen esporádicamente.

Dos principales carga problemas suelen producen cuando deshabilitar la agrupación mientras utiliza el protocolo TCP/IP de SQL Server: se puede ejecutar fuera de puertos anónimos en el equipo cliente o puede exceder la configuración de WinsockListenBacklog predeterminada en el equipo que ejecuta SQL Server.

Para obtener información adicional acerca de puertos anónimos, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

Ajustar la configuración de MaxUserPort y TcpTimedWaitDelay

Observe 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 no utiliza la agrupación de conexiones. Por ejemplo, estas opciones son aplicables en un servidor de servicios de Internet Information Server (IIS) está dando servicio a un gran número de solicitudes HTTP entrantes y que es abrir y cerrar conexiones con un equipo remoto ejecuta SQL Server y que está utilizando el protocolo TCP/IP con la agrupación deshabilitado. Si está habilitada la agrupación, no es necesario que ajustar la configuración MaxUserPort y TcpTimedWaitDelay .

Cuando utiliza el protocolo TCP/IP para abrir una conexión a un equipo que ejecuta SQL Server, la biblioteca de red subyacente SQL Server abre un socket de TCP/IP al equipo que ejecuta SQL Server. Cuando se abre este socket, la biblioteca de red SQL Server no habilita la opción de socket TCP/IP SO_REUSEADDR . Para obtener más información sobre la configuración de socket SO_REUSEADDR , vea el tema "Setsockopt" en Microsoft Developer Network (MSDN).

Tenga en cuenta que específicamente la biblioteca de red SQL Server no habilita la opción de socket de TCP/IP SO_REUSEADDR por motivos de seguridad. Cuando se habilita SO_REUSEADDR , un usuario malintencionado puede apropiarse de un puerto de cliente a SQL Server y utilizar las credenciales que el cliente proporciona acceso a un equipo que está ejecutando SQL Server. De forma predeterminada, porque la biblioteca de red 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 SQL Server en el lado cliente, el socket entra en un estado TIME_WAIT durante cuatro minutos. Si estás rápidamente apertura y cierre conexiones de SQL Server a través de TCP/IP con la agrupación deshabilitado, rápidamente se apertura y cierre sockets TCP/IP. En otras palabras, cada conexión de SQL Server tiene un socket de TCP/IP. Si abre y cierra los 4000 sockets en menos de cuatro minutos rápidamente, alcanzará el valor máximo predeterminado para puertos de cliente anónima y nuevos intentos de conexión de socket fallan hasta que se agote el conjunto de sockets TIME_WAIT existente.

En el lado cliente, quizás tenga que aumentar la configuración de MaxUserPort y TcpTimedWaitDelay se tratan en Q319502 cuando haya deshabilitado la agrupación. Los valores de estos valores se determinan por conexión de SQL Server cuántos abre y cierra se produce en el lado del cliente. Puede examinar cuántos puertos de cliente son en un estado TIME_WAIT mediante la herramienta de 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 su dirección IP de SQL Server que están 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 conexiones establecidas y dos conexiones están en un estado TIME_WAIT: si ejecuta netstat - n y comprueba que cerca a 4000 conexiones a la dirección IP dirección del equipo destino que está ejecutando SQL Server están en un estado TIME_WAIT, puede tanto aumentar el valor de MaxUserPort predeterminado y reducir el valor de TcpTimedWaitDelay de manera que no se ejecuta fuera de los puertos anónima de cliente. Por ejemplo, puede establecer la configuración de MaxUserPort a 20000 y establecer el valor de TcpTimedWaitDelay a 30. Un valor de TcpTimedWaitDelay inferior significa que los sockets de esperar 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 está destinada a cualquier equipo cliente que está hablando con 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 se realizan conexiones de socket TCP/IP locales al equipo local que está ejecutando SQL Server.

Nota Si ajusta la configuración MaxUserPort , recomendamos que reservar el puerto 1434 para su uso por el servicio SQL Server Browser (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:

Ajustar la configuración de WinsockListenBacklog

Para obtener información adicional acerca de la esta configuración de registro específica de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: Cuando la biblioteca de red SQL Server escucha en sockets de TCP/IP, biblioteca de red SQL Server utiliza el escuchar API Winsock. El segundo parámetro para la escucha API es el registro que se permite 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 la longitud máxima, la biblioteca de red SQL Server rechaza inmediatamente más intentos de conexión de socket de TCP/IP. Además, la biblioteca de red SQL Server envía un paquete ACK + RESET.

SQL Server 2000 utiliza una predeterminada escucha la configuración de registro de 5. Esto significa que el equipo que ejecuta SQL Server pasa el valor 5 al parámetro de registro de la escucha API Winsock cuando la escucha API configura los subprocesos de escucha de protocolo TCP/IP en el equipo que ejecuta SQL Server. Puede ajustar la clave de registro de WinsockListenBacklog para especificar un valor diferente para pasarse para 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 Winsock establecer un valor razonable máximo para esta configuración. Por lo tanto, la clave de registro de WinsockListenBacklog ya no se utiliza o necesarios en SQL Server 2005.

El registro de configuración funciona como sigue: supongamos que un servicio arbitrario está escuchando las solicitudes de socket TCP/IP entrantes. Si establece la configuración del trabajo acumulado a 5 y muchas solicitudes de conexión de socket son transmisión continuamente en, el servicio no podrá responder a las solicitudes entrantes tan rápidas tal y como vienen. En este momento, estas solicitudes entrantes en la cola de registro de colas de la capa de sockets TCP/IP y el servicio más adelante puede extraer las solicitudes fuera de esta cola y controlar la solicitud de conexión de socket entrante. Después de la cola se llena, la capa de sockets TCP/IP inmediatamente rechaza las solicitudes adicionales de socket que vienen en mediante el envío un paquete ACK + RESET volver al cliente. El aumento de trabajo acumulado cola tamaño aumenta que el número de pendientes de conexión de socket solicitudes que la capa de sockets TCP/IP pone en cola antes de que se rechazan las solicitudes.

Observe que la configuración de WinsockListenBacklog es específica de SQL Server. SQL Server intenta leer este valor del registro cuando se inicia el servicio de SQL Server por primera vez. Si el valor no existe, se utiliza el valor predeterminado de 5. Si la configuración del registro existe, SQL Server lee la configuración y utiliza el valor proporcionado como el valor de registro al escuchar la API de WinSock se llama como los subprocesos de escucha de socket de TCP/IP se configuran 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 ejecuta SQL Server y busque las solicitudes de conexión de socket que son rechazadas inmediatamente con un ACK + RESET. Si examina los paquetes TCP/IP en Monitor de red, verá un paquete como la siguiente cuando se está produciendo este problema: tenga en cuenta que el puerto de origen está 0x599 o 1433 en decimal. Esto significa que el paquete procede de un equipo típico que ejecuta SQL Server y se está ejecutando en el puerto predeterminado de 1433. También observe que se establecen el campo de confirmación importante y los indicadores de Restablecer la conexión . Si está familiarizado con el filtrado una traza de Monitor de red, puede filtrar el valor de indicadores TCP por 0 x 14 hexadecimal para ver sólo los paquetes ACK + RESET en la traza de Monitor de red.

Observe 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 ejecuta SQL Server no está escuchando en protocolo TCP/IP, por lo que vean los paquetes ACK + RESET no es definitiva de confirmación que experimenta este problema. Si el WinsockListenBacklog es demasiado bajo, algunos conexión intentos de reciban paquetes de aceptación y algunas conexiones recibirán inmediatamente los paquetes ACK + RESET en el mismo marco.

Tenga en cuenta que en muy raras ocasiones, quizás tenga que ajustar esta configuración aunque agrupación está habilitada en los equipos cliente. Por ejemplo, si muchos equipos cliente están hablando con un único equipo que ejecuta 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 esta configuración surta efecto. Sólo detenga y reinicie el servicio SQL Server para que la configuración surta efecto. La configuración del Registro WinsockListenBacklog es sólo para el equipo que está ejecutando SQL Server. No tiene ningún efecto en cualquier equipo cliente que está hablando con SQL Server.