¿Por qué las consultas de SQL Server no usan más de 7 MB / s de E / S de disco?

Tengo un SSD que, utilizando la prueba IOmeter, muestra un rendimiento superior a 200 MB / s. Sin embargo, cuando ejecuto cualquier consulta SQL desde la máquina local, el monitor de recursos de Windows nunca muestra el disco IO por encima de 7 MB / seg. Esto es válido incluso para consultas que tardan más de 2 minutos en ejecutarse. ¿Cuál podría ser el cuello de botella de que solo está usando 7 MB / seg de SSD?

Estoy corriendo:

Windows Server 2012 Standard
SQL Server 2008 r2
Intel i7 3820
32 GB de ram
Sandisk SSD

sql-server sql-server-2008-r2 hardware

— Dean MacGregor
fuente

¿Quizás los datos ya están en la RAM y no se necesita acceso al disco?

— gbn

@DeanMacGregor - ¿Cómo estás consumiendo los resultados? Si en SSMS, ¿qué pasa si prueba la opción de descartar los resultados? ¿Eso cambia algo? También puede intentar mirar sys.dm_os_waiting_tasksmientras se ejecuta la consulta para ver si hay otros tipos de espera que encuentre.

— Martin Smith

¿Son los 200 MB / s para lecturas de acceso aleatorio (lecturas aleatorias para bloques de 4 KB)? Supongo que esto es lo que normalmente haría una base de datos. ¿La consulta escribe en el disco (archivo temporal, conjunto de resultados temporal o tabla)?

@DeanMacGregor: para eliminar eso de la ecuación, puede asignar el resultado a variables escalares (consulta de ejemplo). DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values. Por lo tanto, no se envían resultados al cliente, pero el plan y el IO seguirán siendo los mismos.

— Martin Smith

¿Supone que está interpretando que ASYNC_NETWORK_IO espera que el problema esté relacionado con la red? (Normalmente) no lo es. Es muy probable que @MartinSmith haya sugerido (dos veces) que SSMS o la aplicación que está utilizando no está consumiendo los resultados tan rápido como SQL los está sirviendo. Siga cualquiera de las formas sugeridas de omitir el consumo de las filas y obtendrá una imagen verdadera (r) del rendimiento máximo de E / S.

— Mark Storey-Smith

De la cadena de comentarios, parece que estás interpretando ASYNC_NETWORK_IOesperas para significar que el problema está relacionado con la red. (Normalmente) no lo es.

Como @MartinSmith insinuó (dos veces) la explicación más probable para esto es SSMS o la aplicación que está utilizando que no consume los resultados tan rápido como SQL Server los está sirviendo. Siga cualquiera de los métodos sugeridos para eliminar el consumo de las filas de su medición y obtendrá una imagen verdadera (r) del rendimiento máximo de E / S:

En caso de que aún no lo haya hecho, obviamente DBCC DROPCLEANBUFFERSdeberá asegurarse de que los datos se lean realmente del disco en lugar de la memoria caché del búfer. Se aplican las advertencias habituales de "solo en la prueba, no haga esto en un entorno activo", etc.

Afinando algunos de sus otros comentarios:

Al ejecutar una consulta que devuelve 9 millones de filas, el uso de la CPU se mantendrá en torno al 13% con un 9% atribuible a sqlserver ... ¿no devolvería los resultados más rápido que 3 minutos si todos los datos estuvieran en la RAM?

¿Qué estamos probando exactamente aquí, cómo y por qué? Si su consulta de 9 millones de filas no es una, SELECT * FROM dbo.SomeTableentonces hay 1001 factores que entran en juego, además del rendimiento de E / S sin procesar.

Su Intel I7-3820 es un procesador de 4 núcleos. Si su consulta de prueba no genera un plan paralelo, me sorprendería si pudiera obtener más del 20% de utilización de la CPU del sistema.

Los 3 minutos para devolver 9 millones de filas son muy sospechosos y sugieren que no estamos obteniendo una imagen completa de lo que está probando. Supongo que este es un caso de plan de consulta subóptimo (no paralelo), lleno de operadores de bucle anidado que extraen millones de filas, es decir, no solo una tabla SELECTpara verificar el consumo de E / S.

Yo sugiero:

SELECT *para probar solo IO a través de SQL Server.
Nueva pregunta con el plan de ejecución de su consulta si desea profundizar en por qué no satura el IO.

— Mark Storey-Smith
fuente

En realidad es solo seleccionar * de dbo.sometable. Lo siento, no mencioné eso antes; lo que quise decir fue que podía ejecutar esa consulta desde cualquier tabla. La génesis de mi pregunta fue que noté que mi disco IO era mucho menor de lo que esperaba incluso de una simple consulta de "dame muchos datos". Mi principal preocupación era que si el disco IO es tan bajo, el rendimiento podría mejorarse si la causa raíz del disco bajo IO se eliminó.

— Dean MacGregor