2010-03-12 17 views
5

Soy responsable de una aplicación de terceros (sin acceso a la fuente) que se ejecuta en IIS y SQL Server 2005 (500 usuarios simultáneos, datos de 1TB, 8 servidores IIS). Recientemente comenzamos a ver bloqueos significativos en la base de datos (después de meses de ejecutar esta aplicación en producción sin problemas). Esto ocurre a intervalos aleatorios durante el día, aproximadamente cada 30 minutos, y afecta entre 20 y 100 sesiones cada vez. Todas las sesiones finalmente alcanzan el tiempo de espera de la aplicación y las sesiones abortan.Problema de bloqueo de SQL Server 2005 (ASYNC_NETWORK_IO)

El problema desaparece y luego reaparece gradualmente. El SPID responsable del bloqueo siempre tiene las siguientes características:

  • ESPERA TIPO = ASYNC_NETWORK_IO
  • el SQL que se está ejecutando es “(@claimid varchar (15)) SELECT ClaimID, enrollid, estado, orgclaimid, resubclaimid, primaryclaimid FROM claim WHERE primaryclaimid = @claimid AND primaryclaimid <> claimid) ". Esto es SQL relativamente inocuo que debería solo devolver uno o dos registros, no un conjunto de datos grande .
  • NO OTRAS declaraciones SQL han sido implicadas en el bloqueo, solo esta declaración SQL .
  • Este es un SQL parametrizado para el cual un plan de ejecución está en caché en sys.dm_exec_cached_plans.
  • Este SPID tiene un bloqueo S a nivel de objeto en la tabla de reclamaciones, por lo que todas las ACTUALIZACIONES/INSERTOS de la tabla de reclamaciones también están bloqueadas.
  • HOST ID varía. Los diferentes servidores web son responsables de las sesiones de bloqueo. Por ejemplo, a veces se remontan al servidor web 1, a veces servidor web 2.

Cuando se traza de nuevo al servidor web implicados en el bloqueo, vemos lo siguiente:

  • Siempre hay algún tipo de error relacionado con la aplicación en el registro de eventos en el servidor web, vinculado a la ID de host y el ID de proceso de host de la sesión SQL.
  • Los mensajes de error varían, por lo general algunos tipo de SystemOutofMemory. (Estos mensajes de error parecen ser similares a mensajes de error que hemos visto en el pasado sin tales dramáticas consecuencias . Pensamos que estaba ocurriendo antes, pero no se llegó a bloquear. ¿Por qué ahora?)
  • No se conocen problemas con los adaptadores de red ni en los servidores web ni en el servidor SQL .

(En cualquier caso, el conjunto de registros devuelto por la consulta infractor sería pequeño.)

cosas descartarse:

  • Los índices se desfragmentar regularmente.
  • Estadísticas actualizadas regularmente.
  • Aumento del tamaño de muestra de las estadísticas en claim.primaryclaimid.
  • Recopilación forzada del plan de ejecución en caché .
  • Creó un índice compuesto con primaryclaimid, claimid.
  • No hay problemas de red.
  • No se conocen problemas en el servidor web.
  • Sin cambios en el software de la aplicación en los servidores web .

Nuestra hipótesis es que la cadena de acontecimientos más o menos así:

  1. proceso del servidor Web envía SQL anteriormente.
  2. El servidor SQL ejecuta el SQL, durante , que adquiere un bloqueo en la tabla de reclamaciones .
  3. El proceso del servidor web obtiene un error y muere .
  4. La sesión del servidor SQL se cuelga esperando para que el proceso del servidor web lea el conjunto de datos.
  5. sesiones de SQL Server que necesitan para obtener cerraduras X en las partes de la mesa reclamo (cualquiera procesamiento de reclamaciones) son bloqueado por el bloqueo en la tabla reclamo y permanecen bloqueados hasta que todo golpean el tiempo de aplicación a cabo.

Cualquier sugerencia para la solución de problemas mientras espera la asistencia del proveedor sería muy bienvenida.

¿Hay alguna manera de forzar que SQL Server se bloquee solo en el nivel de fila/página para esta declaración de SQL particular? ¿Hay alguna manera de establecer un umbral en ASYNC_NETWORK_IO solo espera?

Respuesta

7

ASYNC_NETWORK_IO es causado por los clientes que no pueden recibir datos lo suficientemente rápido y llenar los búferes de red (en pocas palabras). No hay una configuración mágica de SQL Server para solucionarlo.

  • reinicio el cliente (aunque sea servidor web)
  • asegurar tarjetas de red están configurados correctamente (firmware, full duplex, etc)
  • aseguran cables físicos están bien (las pérdidas de paquetes, etc?)
  • etc.

es no un problema de SQL Server, como tal ...

ASYNC_NETWORK_IO se produce en la red escribe cuando la tarea es bloqueado detrás la red.Verifique que el cliente esté procesando datos del servidor.

+0

Gracias por la respuesta rápida e informativa. Vimos de nuevo los adaptadores/conexiones de red física en todo el servidor web y creemos que podemos descartar esto. La declaración de SQL que está implicada en el bloqueo normalmente devolverá un conjunto de datos muy pequeño (máximo 3 registros), no lo suficiente como para desbordar los almacenamientos intermedios de red y producir una espera prolongada de ASYNC_NETWORK_IO. Sin embargo, existe una condición de límite (@claimid = '') que devolvería millones de registros. Esto bien podría inducir a ASYNC_NETWORK_IO, incluso en un servidor web configurado correctamente. Esto es lo que buscaremos a continuación. – ivankolo

1

que tenía el mismo problema y que se resolvió cuando He desactivado el antivirus Kaspersky en el cliente.

Cuestiones relacionadas