Voy a comentar los pasos a seguir, para abordar los problemas relacionados con: "General Network error", "Communication link failure", or "A transport-level error", “Time-out”. Hablaremos del TCP Chimney, WinsockListenBacklog, SynAttackProtect, configuración de antivirus, Network Monitor (NetMon), etc.
Paso 1:
Para empezar debemos revisar la Versiónn de los drivers de las tarjetas de red, y verificar si hay actualizaciones aconsejables. Deberemos revisar de nuevo la configuración de TCP Chimney ya que en algunos casos la instalación de un nuevo driver modifica los parámetros. Puedes utilizar el siguiente enlace web para realizar esta configuración:
"General Network error," "Communication link failure," or "A transport-level error"
http://support.microsoft.com/kb/942861 este link nos dice para un windows 2003 que hagamos:
Para evitar este problema, deshabilite la característica de descarga TCP Chimney. Para ello, siga estos pasos:
1. Haga clic en Inicio , haga clic en Ejecutar , escriba cmd y, a continuación, presione ENTRAR.
2. En el símbolo del sistema, escriba el comando siguiente y presione ENTRAR:
netsh int ip establece chimney DISABLED
Nota No es necesario reiniciar el servidor después de ejecutar este comando.
Si se disminuye el rendimiento de Windows Server 2003 después de deshabilitar la característica de descarga TCP Chimney, siga estos pasos adicionales:
1. Haga clic en Inicio , haga clic en Ejecutar , escriba Regedit y, a continuación, haga clic en Aceptar .
2. Busque la siguiente subclave del Registro:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
3. Haga doble clic en la entrada de registro EnableTCPChimney .
4. En el cuadro de diálogo Editar valor DWORD , escriba 0 en el cuadro de datos de valor y, a continuación, haga clic en Aceptar .
5. Haga doble clic en la entrada de registro EnableRSS .
6. En el cuadro de diálogo Editar valor DWORD , escriba 0 en el cuadro de datos de valor y, a continuación, haga clic en Aceptar .
7. Haga doble clic en la entrada de registro EnableTCPA .
8. En el cuadro de diálogo Editar valor DWORD , escriba 0 en el cuadro de datos de valor y, a continuación, haga clic en Aceptar .
9. Reinicie el servidor.
Paso 2:
Por otro lado, comprueba que el servicio de Antivirus se encuentra configurado excluyendo los directorios de datos de SQL Server y Reporting Services.
Paso 3:
Vamos a pasar a la tercera parte del plan y capturar trazas de red en el servidor de SQL Server. Para ello:
1. Nos vamos al nodo activo del clúster e instalamos la última versión de Network Monitor (NetMon) que podrás encontrar en el siguiente enlace web:
Microsoft Network Monitor 3.3,
http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en
2. Si disponemos de algún servidor o PC cliente en el que podamos reproducir el problema, o en el que frecuentemente se produzca el problema, instalaremos también ahí la última versión de NetMon
3. Abrimos Netmon y lo configuramos con un buffer de 150 MB en a través de la opción Tools > Options > Capture como se muestra:
4. Hacemos clic en el botón "Start" para comenzar la traza. Si tenemos Netmon instalado también en una máquina cliente configurarnos los mismos parámetros de buffer de traza y lanzamos también el proceso de captura
5. Esperamos a que se reproduzca el error y paramos la capturar haciendo clic en el botón "Stop" en el servidor de SQL Server y, si disponemos de un cliente, también en el cliente
6. Guardamos la traza de Network Monitor con la opción "Save as", usaremos el nombre del servidor de SQL Server como nombre del fichero y nos aseguraremos de que la opción "All captured frames" está seleccionada
7. Guardaremos en un bloc de notas la salida del comando ipconfig.exe /all en el nodo del clúster en el que hemos ejecutado NetMon
En este punto, es interesante estudiar lo resultados y ver que nos dice la información:
- Traza de NetMon capturada en el servidor de SQL Server
- Traza de NetMon capturada en el cliente donde se produce el error, si existe
- Fichero de texto con la salida del comando ipconfig.exe /all en el servidor de SQL Server
- Fichero de texto con la salida del comando ipconfig.exe /All en el cliente, si existe
- Fichero ERRORLOG de SQL Server (el último, que no tiene ninguna extensión)
- Visor de Eventos de Aplicaciones y de Sistema en modo TXT del Servidor de SQL Server. Puedes exportar esta información desde el propio Visor de Eventos de Windows
- Visor de Eventos de Aplicaciones y de Sistema en modo TXT del cliente donde se produce el error, si existe
Cabe la posibilidad de que en estas trazas no encontremos ningún error, con lo que descartaríamos que el error se encuentra en el servidor de SQL Server y tendríamos que centrarnos en algún elemento de red o alguna propiedad común a todos los clientes.
Paso 4:
Es posible que el problema no esté relacionado con SQL Server sino con el propio servidor Windows.
La primera posibilidad es que nos encontremos con un problema referido al valor de configuración del parámetro de red WinsockListenBacklog que es un parámetro de configuración específico para SQL Server 2000 que determina el periodo de espera de cada puerto TCP/IP, esto se encuentra mejor explicado en el siguiente enlace web:
Description of TCP/IP settings that you may have to adjust when SQL Server connection pooling is disabled,
http://support.microsoft.com/default.aspx?scid=kb;EN-US;328476
"The backlog setting works as follows: Suppose an arbitrary service is listening for incoming TCP/IP socket requests. If you set the backlog setting to 5 and many socket connection requests are continually streaming in, the service may not be able to respond to the incoming requests as fast as they come in […] After the queue fills up, the TCP/IP socket layer immediately rejects any additional socket requests that come in by sending an ACK+RESET packet back to the client. Increasing the backlog queue size increases the number of pending socket connection requests that the TCP/IP socket layer queues before requests are rejected."
Cuando la carga de red en el servidor es muy alta el valor por defecto de WinsockListenBacklog puede ser insuficiente para dar soporte a la misma.
Otra posibilidad es la relacionada con el valor SynAttackProtect que es una funcionalidad existente en Windows 2000 y que fue implementada por defecto en Windows Server 2003 para prevenir ataques de denegación de servicio (DoS) pero que puede originar problemas cuando el servidor se encuentra con mucha carga y gestionando un alto número de conexiones cliente. Puedes encontrar más información sobre este parámetro en el siguiente enlace web:
How to harden the TCP/IP stack against denial of service attacks in Windows 2000,
http://support.microsoft.com/kb/315669
Una tercera posibilidad tendría que ver con el cliente y no con el servidor. Cabe la posibilidad de que el cliente haya sido configurado para no usar 'connection pooling', lo que puede tener un efecto nocivo en SQL Server ya que de este modo no se reúsan conexiones existentes sino que cada conexión al servidor abre su conexión de forma independiente. Puedes encontrar más información sobre esto en el siguiente enlace web:
Pooling,
http://en.wikipedia.org/wiki/Database_connection#Pooling
El no usar 'connection pooling' en la aplicación cliente origina una carga extra en el servidor de SQL Server que puede provocar errores del tipo "General Network Error".
El plan de acción sería:
1. Necesitamos identificar si las aplicaciones que provocan estos errores son siempre las mismas.
2. Debemos confirmar que la aplicación está haciendo uso de 'connection pooling'. En este punto necesitaremos implicar a vuestro grupo de desarrollo. Este artículo os puede servir de referencia para esta comprobación:
Connection Pooling (ADO.NET),
http://msdn.microsoft.com/en-us/library/bb399543.aspx
Este paso es muy importante ya que el problema puede no tener su causa raíz en el servidor, sino en la aplicación. El problema de "General Network Error" aparece asociado en muchas ocasiones a aplicaciones cliente de SQL Server que no hacen uso de 'connection pooling'.
3. Una vez revisados los pasos anteriores, vamos a configurar el valor de WinsockListenBacklog en el servidor de SQL Server utilizando el registro. Este valor debe de ser configurado en ambos nodos, si tu entrono esta en un cluster, y requiere un reinicio del servidor Windows. Para ello realizarnos el siguiente paso:
Nos vamos a la siguiente clave del registro:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerInstance NameMSSQLServerSuperSocketNetLib
y añadimos la siguiente entrada:
Value Name: WinsockListenBacklog
Data Type: REG_DWORD
Data: 10
El valor por defecto de WinsockListenBacklog cuando esta clave no existe es '5'. Vamos a ir aumentado su valor de 5 en 5 para comprobar si el número de errores en la aplicación cliente se sigue produciendo con la misma intensidad
4. Si las acciones realizadas antes no dan ningún resultado seguiremos las indicaciones en la sección "Resolution" del siguiente KB:
A BizTalk Server Host instance fails, and a "General Network" error is written to the Application log when the BizTalk Server-based server processes a high volume of documents,
http://support.microsoft.com/kb/899599/en-us
Es necesario que el cambio en el registro se realice en abrimos nodos y que los servidores Windows sean reiniciados para que el cambio tenga efecto.
Si con esto no se aprecia ningún cambio pasaremos a desactivar lo servicios no esenciales del servidor para comprobar si alguno de ellos no está causando el problema. Por ejemplo, los servicios de Antivirus instalan un Filter Driver de red que puede dar lugar a problemas.
Apunte realilzado por Norman M. Pardell
Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.
