Declaración SELECT remota lenta debido al largo "tiempo de procesamiento del cliente", pero localmente rápido

Mientras está conectado a nuestro servidor de producción (SQL Server 2008, máquina muy potente), esta instrucción SELECT demora 2 segundos , escupiendo todos los campos (4 MB de datos en total).

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

Desde cualquier otro cuadro en la misma red (conexión mediante autenticación de SQL o autenticación de Windows), la misma consulta demora 1 minuto y 8 segundos .

Estoy probando con esta declaración muy simple para ilustrar que no es un problema de indexación o un problema relacionado con consultas. (Tenemos problemas de rendimiento con todas las consultas en este momento ...)

Las filas vienen en trozos, y no todos a la vez. Obtengo mis primeras filas al instante, y luego espero más de 1 minuto para que lleguen los lotes de filas.

Estas son las estadísticas del cliente de la consulta, cuando se ejecuta desde el cuadro remoto:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

Podemos ver que el "Tiempo de procesamiento del cliente" es igual al tiempo total de ejecución.

¿Alguien sabe qué pasos puedo tomar para diagnosticar por qué la transferencia de los datos reales está tomando tanto tiempo?

¿Existe un parámetro de configuración de SQL que restrinja o limite la velocidad de transferencia de datos entre máquinas?

Su problema definitivamente está relacionado con la red, según su información. Como tal, debe tratarse con profesionales de la red (yo no soy el indicado).

Cosas que pueden ayudar:

• Tarjetas NIC más rápidas (en el servidor SQL).
• Adición de tarjeta / subred NIC específica / asignada entre los servidores (servidor web y SQL Server).

¿Está el servidor web en la misma subred que el servidor SQL?

¿Hay enrutadores / puentes, etc., entre ellos?

No hay muchos cambios posibles en el servidor SQL:

• SQL Server envía los datos de salida con el "protocolo TDS" patentado de MS.
• El tamaño predeterminado del búfer TDS es de 4 KB. Ver en MSDB: "Opción de tamaño de paquete de red"
• Comprimir los datos (con SQL Server o una aplicación externa) depende de la naturaleza de los datos.

Está utilizando un tamaño predeterminado: consulte sus estadísticas: "Paquetes TDS recibidos del servidor 1216" (4MB / 1K = 4KB). Sí, el tamaño del búfer TDS se puede cambiar: consulte en google: "Tamaño del lote del protocolo TDS"

Buena discusión sobre el tema: "¿el tamaño del paquete de red de sql realmente determina el tráfico de ida y vuelta?"

Sin embargo, cambiar el tamaño del paquete TDS tendrá (inevitablemente) efectos impredecibles y solo debe usarse en la producción en casos excepcionales.

El cambio de arquitectura o la introducción del almacenamiento en caché de datos en el nivel medio también ayudaría.

Este problema esta resuelto ahora.

Era un problema de red, y la caja SQL estaba usando una tarjeta NIC de 100 MB / s , en lugar de una tarjeta NIC de 10 GB / s ...

Un cambio en la configuración de la red para usar la tarjeta de red correcta ha solucionado el problema. Ahora estamos obteniendo un rendimiento similar para todas las consultas del cuadro SQL de producción y de otros cuadros en la red.

Gracias a todos por su ayuda.

En la lectura inicial, parece que está experimentando algunos problemas de latencia de red. ¿Has mirado algunos de los contadores de Network Perfmon? Esos pueden darle alguna indicación de lo que está sucediendo con la red.

Cita de ¿Qué mostradores de Perfmon debo monitorear y qué significa cada uno de ellos?

RED IO

Para medir la E / S de red, puede usar los siguientes contadores:

Interfaz de red Bytes Total / seg.

Umbral: valores sostenidos de más del 80 por ciento del ancho de banda de la red.

Importancia: este contador indica la velocidad a la que se envían y reciben los bytes a través de cada adaptador de red. Este contador le ayuda a saber si el tráfico en su adaptador de red está saturado y si necesita agregar otro adaptador de red. La rapidez con la que puede identificar un problema depende del tipo de red que tenga y de si comparte el ancho de banda con otras aplicaciones.

Interfaz de red Bytes recibidos / seg.

Este contador indica la velocidad a la que se reciben los bytes en cada adaptador de red. Puede calcular la velocidad de los datos entrantes como parte del ancho de banda total. Esto le ayudará a saber que necesita optimizar los datos entrantes del cliente o que necesita agregar otro adaptador de red para manejar el tráfico entrante.

Interfaz de red Bytes enviados / seg.

Este contador indica la velocidad a la que se envían los bytes a través de cada adaptador de red. Puede calcular la velocidad de los datos entrantes como parte del ancho de banda total. Esto le ayudará a saber que necesita optimizar los datos que se envían al cliente o que necesita agregar otro adaptador de red para manejar el tráfico saliente.

ServerBytes Total / seg.

Este valor no debe ser más del 50 por ciento de la capacidad de la red.

Este contador indica el número de bytes enviados y recibidos a través de la red. Los valores más altos indican el ancho de banda de la red como el cuello de botella. Si la suma del total de bytes / segundo para todos los servidores es aproximadamente igual a las velocidades máximas de transferencia de su red, es posible que necesite segmentar la red.

Procesador% Tiempo de interrupción

Este contador indica el porcentaje de tiempo que el procesador pasa recibiendo y reparando interrupciones de hardware. Este valor es un indicador indirecto de la actividad de los dispositivos que generan interrupciones, como los adaptadores de red.

Interfaz de red (*) Longitud de la cola de salida

Este contador verifica cuántos hilos están esperando en el adaptador de red. Si hay muchos subprocesos esperando en el adaptador de red, entonces es probable que el sistema sature la E / S de la red debido a la latencia de la red o al ancho de banda de la red.

La longitud de la cola de salida es la longitud de la cola del paquete de salida (en paquetes). Si esto es más largo que dos, hay demoras y el cuello de botella debe ser encontrado y eliminado, si es posible. Dado que las solicitudes son puestas en cola por la Especificación de interfaz del controlador de red (NDIS) en esta implementación, siempre será 0.

Algunas preguntas preliminares: 1) El servidor tiene un cliente SQL en Prod. configuración de la máquina del servidor, ¿verdad? Entonces, si realiza la misma consulta desde el cliente ubicado en la misma máquina, ¿se completará en 2 segundos? ¿Intentaste hacer esto? ¿Son realmente 2 segundos? 2) Usted mencionó que la configuración de su entorno de producción ha cambiado (o el servidor de producción se ha movido a otra red / reconstrucción total del servidor realizada), ¿verdad? ¿Cuál fue el tiempo de consumo de consultas en el antiguo entorno de producción?

Desde cualquier otro cuadro en la misma red ... la misma consulta toma 1 minuto, 8 segundos. 3) ¿Está diciendo que la consulta vuelve y se consume desde el cliente, ubicado en cualquier máquina en la red dada (espere su máquina específica) en aproximadamente 70 segundos? ¿Entendí correctamente? 3.1 Incidentalmente, ¿cuál es el momento para el consumo de esta consulta, aceptable para la empresa? 4) Sin embargo, está especificando que para un equipo cliente específico que está utilizando el tiempo de consumo de salida de la consulta es: Tiempo de ejecución del cliente 15:30: 48 15 minutos? (y esta vez claramente no es aceptable) ¿Correcto? 5) ¿Entonces el problema se limita a una sola máquina cliente? ¿O a CUALQUIER máquina cliente / nivel medio, etc. (en un nuevo entorno)? 6) ¿Cuál es el retraso que muestra ping? de la computadora del cliente al servidor? 7) ¿Usted (o el administrador de la red) ejecutó tracert en ambos sentidos (de cliente a servidor, de servidor a cliente)? Cuantos saltos ¿Cuál es el tiempo combinado? 8) ¿Está viva la antigua red de producción? ¿Puedes comparar usando Ping y Traceroute? ¿Cuál fue el tiempo y los saltos entre el cliente y el servidor allí?

Por curiosidad: ¿este es un ejemplo de la consulta? o la redacción exacta de la consulta? La consulta realmente NO contiene la cláusula WHERE? De acuerdo conmigo en que esto es muy inusual. ¿La tabla tiene un índice agrupado o es un montón? La tabla contiene cuántas filas en total? ¿La mesa está muy fragmentada? Por curiosidad: ¿por qué SELECCIONAR TOP NNN? ¿Por qué no SET ROWCOUNT NNN - luego SELECT *? Esta consulta es emitida cuántas veces por el cliente por día? 1? 100? 1MLN? ¿Los datos subyacentes son estáticos o dinámicos y cambian mucho? ¿Cuánto (0.01 por ciento por día? 1 por ciento por día? 10 por ciento por día?) La salida de la consulta se procesa mediante programación? (¿no lo hace un usuario?) ¿Por qué no se almacena en caché / no se almacena en el nivel medio? gracias Alexei