¿Por qué io_stall_writes_ms es mucho más alto para tempdb?

Tenemos los archivos de datos del usuario y del sistema en la misma unidad de disco. El (io_stall_write_ms / (1.0 + num_of_writes)) está por debajo de 2 para los archivos de usuario, pero los archivos tempdb suelen tener más de 400. Veo eso en algunos servidores y tengo curiosidad si hay una razón por la que toma más tiempo escribir en tempdb que un archivo de datos de base de datos normal.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Gracias,

Respuesta corta: Ver puestos de IO más altos puede o no ser un problema en sí mismo. Debe buscar más información para saber si tiene un problema. Parece un poco alto, sí, pero ¿estás sufriendo? Si es así, probablemente se deba a que su sistema IO no está manejando la carga correctamente (porque no puede hacerlo, porque tiene todo en una unidad u otra razón) o está haciendo demasiado en TempDB (cambiando el primer problema: el rendimiento de IO: es probablemente una solución más fácil y más eficiente, pero primero determine si tiene un problema)

La discusión / respuesta más larga:

Aquí hay dos preguntas en juego:

1.) ¿Qué hago cuando veo puestos de IO altos?

En primer lugar, "alto" está en el ojo del espectador. Si le preguntara a 10 DBA qué es "demasiado alto" para los puestos de E / S, probablemente obtendría 2-3 respuestas diferentes con números, 5-6 respuestas "Depende" y una mirada en blanco. Mi suposición es que un promedio de 400 ms es potencialmente demasiado alto aquí, especialmente cuando los otros DB son 2 ms o menos para el tiempo de pérdida promedio.

Independientemente de qué base de datos esté viendo los puestos altos, debe abordarlo de la misma manera. Un puesto de E / S es lo que parece ... Una solicitud de E / S tarda más de lo esperado ... Se estanca. Estas suceden. Suceden todo el tiempo en un sistema con recursos compartidos y recursos finitos (realmente todos nuestros sistemas). Se convierten en un problema cuando los puestos se convierten en problemas de rendimiento o conducen a ellos. Así que confío en que está buscando aquí como una parte proactiva de la supervisión o porque estaba experimentando problemas de rendimiento que está solucionando. Tampoco queremos perdernos solo en puestos de E / S. Estamos viendo una pieza del rompecabezas y no el panorama general. Puede ser problemático solo mirar las estadísticas de espera o las estadísticas del archivo desde que SQL se reinició por última vez porque está mirando todo el tiempo y alguna ventana de mantenimiento o ventana de carga pesada podría sesgar los contadores. Así que asegúrese de mirar la imagen completa.

Pero cuando sospecho que tengo un problema de rendimiento del disco o veo algo en una consulta como esta, normalmente sigo un proceso que se parece a:

1. Mira las estadísticas de espera en el servidor. @swasheck compartió un excelente enlace como comentario en la siguiente respuesta. Esto lo lleva a la publicación de Paul Randal sobre mirar y analizar estadísticas de espera en SQL Server. Ve allí. ¿Qué tipo de esperas estás viendo? ¿Ves espera relacionados con la actuación IO ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, etc.?). Si hace esto, es otra indicación de que tiene algunos problemas de rendimiento relacionados con IO, al igual que los bloqueos de IO. Pero te da otra forma de acuerdo aquí.
2. Mira el rendimiento de IO. En particular, mire dentro de perfmon en los mostradores Physical Disk:Avg Disk Sec/Ready Avg Sec Disk Sec/Write. Estos miden tu latencia. Observe estos contadores durante un período de tiempo guardado en un archivo de registro de rendimiento. ¿Qué viste para los promedios? Si ve números de más de 0.020 segundos (20 ms), esto podría ser un problema. Si ve números de más de 40-50 ms de promedio o más, es una indicación más firme de un problema. También mira tus picos? ¿Qué tan alto van y cuánto duran? Si ve picos en los cientos de ms y duran decenas o decenas de segundos o más y / o ocurren con frecuencia, es más probable que tenga un problema con su rendimiento de IO para su carga de trabajo.
3. Mira tu configuración IO. ¿Qué es? Discos locales? SAN? Matriz de almacenamiento? ¿Qué tipo de PIO y en todo momento debería ver de esto? ¿Es suficiente para lo que estás tratando de hacer? Es posible que haya reducido su IO para su carga de trabajo. No solo mire sus ejes físicos, configuraciones RAID, etc. Mire sus rutas a sus discos. ¿Está empujando todo a través de un solo enlace de 1GB que está compartiendo con mucho otro tráfico? ¿Puede mirar las métricas de rendimiento del disco desde la perspectiva del almacenamiento?

( Nota: para este análisis de estadísticas de espera y análisis de rendimiento, observe varios períodos y tipos de uso. ¿Tiene estadísticas de uso diferentes por la noche que durante el día? ¿Ventanas de procesamiento por lotes? ¿Ventanas de mantenimiento donde reconstruye muchos índices? Mire estas herramientas durante cada uno de estos períodos y entienda lo que está viendo para cada uno)

Otra consideración de rendimiento de IO aquí:

• Usted dijo que las bases de datos del sistema y las bases de datos de usuario son compartidas ¿Es esta producción? Si es así, ese no es siempre el mejor escenario. ¿También comparte archivos de registro y archivos de datos en las mismas unidades? Ese tampoco es el mejor escenario. ¿Qué más comparte este almacenamiento? En un mundo donde te preocupas por los husillos y los grupos y discos de ataque, y tienes que tomar decisiones sobre quién obtiene los mejores discos, tiendo a hacerlo (como regla general ... lo cual no es bueno tener en el mundo DB) pero este tiende a ser cierto) ir con mi más rápido y más dedicado a TempDB (más sobre eso a continuación), luego los archivos de registro, luego los archivos de datos. En un mundo donde tiene una gran pila de discos en un dispositivo como NetApp, Dell Equal Logic o EMC VNX, etc.

2.) ¿Cuáles son algunas razones por las que TempDB podría ser mayor?

Entonces TempDB es una base de datos y puede tener paradas de E / S como cualquier otra base de datos como acabo de comentar. Pero, ¿cuáles son algunas razones por las que TempDB puede tener lecturas más altas? (no exhaustivo, agradezco adiciones o pensamientos en ediciones, otras respuestas o comentarios) -

1. Debido a su código: ¿está utilizando TempDB mucho en su código a propósito? ¿Muchas tablas temporales y variables de tabla creadas y destruidas? ¿Haciendo muchas cosas en TempDB como esta? Eso no es malo ni bueno necesariamente, pero puede mirar eso y comprender su patrón de uso intencional de TempDB.
2. TempDB es un caballo de batalla compartido: TempDB es una base de datos que se utiliza como espacio temporal para objetos temporales definidos por el usuario y varias tablas de trabajo y operaciones utilizadas por toda su instancia de SQL. ¿Cuántas bases de datos de usuario hay? ¿Qué tipo de carga de trabajo ves en general? TempDB es un recurso para compartir todas las cosas.
3. Consultas ineficientes y memoria insuficiente: tal vez hay consultas que no utilizan índices con suficiente precisión o que están realizando operaciones de exploración y clasificación de gran tamaño. Grandes operaciones de hash, y la memoria en el servidor no es suficiente para estas. Estas operaciones "se derramarán" a TempDB como tablas de trabajo detrás de escena. A veces esto se puede evitar mirando sus planes de consulta e indexando o ajustando la consulta. A veces sucede (más aún en las cargas de trabajo de almacén, creo). Si tiene suficiente memoria, esto puede ayudar, pero estas consultas aún pueden derramarse a veces. Mira esto también.
4. ¿Está utilizando el nivel de aislamiento de instantáneas de lectura confirmada con una buena cantidad de actualizaciones en su sistema? Esto también puede resultar en una mayor actividad de TempDB.

El punto es: TempDB se usa de muchas maneras, y no me sorprende en absoluto verlo como una de sus bases de datos más ocupadas, si no la más ocupada. Tampoco me sorprende cuando veo que tiene el mayor número de puestos y el promedio más alto de todas las bases de datos en el sitio de un cliente. Es la naturaleza de su carga de trabajo a veces. Mirar algunas de las cosas que he mencionado aquí ciertamente puede ayudarlo a determinar si estos números indican un problema y, de ser así, cómo profundizar en su resolución.

TempDB se comparte entre todas las bases de datos de la instancia. Por lo tanto, a veces puede haber contención dentro de TempDB para ciertas páginas: SGAM , GAM y PFS . En pocas palabras, estas páginas realizan un seguimiento de lo que se ha utilizado en TempDB hasta ahora y dónde hay espacio disponible para un nuevo uso.

Por lo general, esto se soluciona agregando múltiples archivos de datos a TempDB. Hay algunas filosofías diferentes en cuanto al número correcto, pero todos están de acuerdo en que debe tener más de uno.

Aquí hay algunas consultas para ejecutar ...

Este le mostrará cuántos archivos tiene TempDB y dónde están ubicados.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Este le mostrará cuántas CPU y núcleos tiene.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Este le mostrará cuántos nodos y núcleos NUMA por nodo NUMA tiene.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Este le mostrará qué páginas están experimentando esperas en TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Aquí hay un artículo que profundiza un poco más en el tema de contención de la página.

OK, ahora la parte de filosofía ... :-)

Para mí, si estoy en un sistema SMP , solo quiero tantos archivos como la mitad de los núcleos totales .

Si estoy en un sistema NUMA , entonces solo quiero tantos archivos como núcleos por nodo NUMA .

Sin embargo, rara vez veo alguna mejora por tener más de cuatro archivos para TempDB. Por lo general, comienzo con cuatro y superviso la contención como se explica en el artículo al que me vinculé.

Si sigo viendo problemas, entonces agregaría dos más. Verifique nuevamente, agregue más y repita hasta que desaparezca la contención.