Las solicitudes de E / S tardan más de 15 segundos

Por lo general, nuestras copias de seguridad completas semanales finalizan en aproximadamente 35 minutos, con las copias de seguridad diarias en 5 minutos. Desde el martes, los diarios han tardado casi 4 horas en completarse, mucho más de lo necesario. Casualmente, esto comenzó a suceder justo después de que obtuvimos una nueva configuración de SAN / disco.

Tenga en cuenta que el servidor se está ejecutando en producción y no tenemos problemas generales, funciona sin problemas, excepto por el problema de E / S que se manifiesta principalmente en el rendimiento de la copia de seguridad.

Mirando dm_exec_requests durante la copia de seguridad, la copia de seguridad está constantemente esperando ASYNC_IO_COMPLETION. ¡Ajá, entonces tenemos contención de disco!

Sin embargo, ni el MDF (los registros se almacenan en el disco local) ni la unidad de copia de seguridad tienen actividad (IOPS ~ = 0, tenemos mucha memoria). Longitud de la cola del disco ~ = 0 también. La CPU ronda el 2-3%, tampoco hay problema.

El SAN es un Dell MD3220i, el LUN que consta de unidades SAS de 6x10k. El servidor está conectado a la SAN a través de dos rutas físicas, cada una a través de un conmutador separado con conexiones redundantes a la SAN, un total de cuatro rutas, dos de ellas activas en cualquier momento. Puedo verificar que ambas conexiones estén activas a través del administrador de tareas, dividiendo la carga perfectamente de manera uniforme. Ambas conexiones están ejecutando 1G full duplex.

Solíamos usar marcos jumbo, pero los he desactivado para descartar cualquier problema aquí, sin cambios. Tenemos otro servidor (mismo OS + config, 2008 R2) que está conectado a otros LUN y no muestra problemas. Sin embargo, no ejecuta SQL Server, sino que solo comparte CIFS encima de ellos. Sin embargo, una de las rutas preferidas de los LUN está en el mismo controlador SAN que los LUN problemáticos, así que también lo descarté.

Ejecutar un par de pruebas SQLIO (archivo de prueba 10G) parece indicar que IO es decente, a pesar de los problemas:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Me doy cuenta de que estas no son pruebas exhaustivas de ninguna manera, pero me hacen sentir cómodo al saber que no es una basura completa. Tenga en cuenta que el mayor rendimiento de escritura es causado por las dos rutas MPIO activas, mientras que la lectura solo usará una de ellas.

La comprobación del registro de eventos de la aplicación revela eventos como estos dispersos:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

No son constantes, pero suceden regularmente (un par por hora, más durante las copias de seguridad). Junto con ese evento, el registro de eventos del sistema publicará estos:

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Esto también ocurre en el servidor CIFS no problemático que se ejecuta en el mismo SAN / Controlador, y desde mi Google parece que no son críticos.

Tenga en cuenta que todos los servidores usan las mismas NIC: Broadcom 5709Cs con controladores actualizados. Los servidores en sí son Dell R610.

No estoy seguro de qué verificar a continuación. ¿Alguna sugerencia?

Actualización - Ejecutando perfmon
Intenté grabar el Avg. Disco seg / lectura y escritura de contadores de rendimiento mientras realiza una copia de seguridad. La copia de seguridad comienza de manera vertiginosa, y luego básicamente se detiene en un 50%, arrastrándose lentamente hacia el 100%, pero tarda 20 veces el tiempo que debería.

Muestra las dos rutas SAN que se están utilizando y luego las deja.

La copia de seguridad se inició alrededor de las 15:38:50; observe que todo se ve bien, y luego hay una serie de picos. No me preocupan las escrituras, solo las lecturas parecen colgar.

Tenga en cuenta muy poca acción de encendido / apagado, aunque un rendimiento increíble al final.

Tenga en cuenta un máximo de 12 segundos, aunque el promedio es bueno en general.

Actualización: copia de seguridad en el dispositivo NUL
Para aislar problemas de lectura y simplificar las cosas, ejecuté lo siguiente:

BACKUP DATABASE XXX TO DISK = 'NUL'

Los resultados fueron exactamente los mismos: comienza con una lectura en ráfaga y luego se detiene, reanudando las operaciones de vez en cuando:

Actualización - IO puestos
me encontré con la consulta dm_io_virtual_file_stats de Jonathan Kehayias y Ted Kruegers libro (página 29), según lo recomendado por Shawn. Mirando los 25 archivos principales (un archivo de datos cada uno, todos los resultados son archivos de datos), parecería que las lecturas son peores que las escrituras, tal vez porque las escrituras van directamente al caché SAN, mientras que las lecturas en frío deben golpear el disco, aunque solo es una suposición .

Actualización: estadísticas de espera
Hice tres pruebas para recopilar algunas estadísticas de espera. Las estadísticas de espera se consultan utilizando el script Glenn Berry / Paul Randals . Y solo para confirmar: las copias de seguridad no se realizan en cinta, sino en un iSCSI LUN. Los resultados son similares si se realizan en el disco local, con resultados similares a la copia de seguridad NUL.

Estadísticas borradas Corrió durante 10 minutos, carga normal:

Estadísticas borradas Funcionó durante 10 minutos, carga normal + copia de seguridad normal en ejecución (no se completó):

Estadísticas borradas Funcionó durante 10 minutos, carga normal + copia de seguridad NUL en ejecución (no se completó):

Actualización - Wtf, Broadcom?
Basado en las sugerencias de Mark Storey-Smiths y las experiencias previas de Kyle Brandts con los NIC de Broadcom, decidí experimentar un poco. Como tenemos múltiples rutas activas, podría cambiar relativamente fácilmente la configuración de las NIC una por una sin causar interrupciones.

Deshabilitar TOE y Large Send Offload produjo una ejecución casi perfecta:

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Entonces, ¿cuál es el culpable, TOE o LSO? TOE habilitado, LSO deshabilitado:

Didn't finish the backup as it took forever - just as the original problem!

TOE deshabilitado, LSO habilitado - buen aspecto:

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

Y como control, deshabilité tanto TOE como LSO para confirmar que el problema desapareció:

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

En conclusión, parece que el motor de descarga TCP de Broadcom NIC habilitado causó los problemas. Tan pronto como TOE fue deshabilitado, todo funcionó de maravilla. Supongo que no voy a pedir más NIC Broadcom en el futuro.

Actualización - Abajo va el servidor CIFS
Hoy, el servidor CIFS idéntico y funcional comenzó a exhibir solicitudes de E / S colgadas. Este servidor no ejecutaba SQL Server, simplemente Windows Web Server 2008 R2 que sirve recursos compartidos a través de CIFS. Tan pronto como desactivé TOE también, todo volvió a funcionar sin problemas.

Solo confirma que nunca más volveré a usar TOE en las NIC de Broadcom, si no puedo evitar las NIC de Broadcom en absoluto, eso es.

Tenga en cuenta que todos los servidores usan las mismas NIC: Broadcom 5709Cs con controladores actualizados. Los servidores en sí son Dell R610.

Kyle Brandt tiene una opinión sobre las tarjetas de red Broadcom que refleja mi propia experiencia (repetida).

Broadcom, Die Mutha

Mis problemas siempre se han asociado con las funciones de descarga TCP y en el 99% de los casos, la desactivación o el cambio a otra tarjeta de red ha resuelto los síntomas. Un cliente que (como en su caso) usa servidores Dell, siempre ordena las NIC Intel separadas y deshabilita las tarjetas Broadcom integradas en la compilación.

Como se describe en esta publicación de blog de MSDN , comenzaría con la desactivación en el sistema operativo con:

netsh int ip set chimney DISABLED

IIRC puede ser necesario deshabilitar las funciones en el nivel del controlador de la tarjeta en algunas circunstancias, ciertamente no está de más hacerlo.

No es que sea un experto en SAN / disco (hay personas aquí que saben más que yo) ... Solo comparto lo que he hecho un poco y sobre todo leo :)

Jonathan Kehayias y Ted Krueger escribieron un libro "Solución de problemas de SQL Server" que tiene buena información sobre el rendimiento del disco. Puede obtener el PDF de forma gratuita desde aquí . (También podría comprar la edición impresa de esto para mi escritorio).

De todos modos, tienen una buena consulta que se puede usar para verificar sys.dm_io_virtual_file_stats y verificar la latencia promedio en sus archivos de datos. Puede encontrar que RAID10 no es la configuración ideal para que residan los archivos de datos.