¿Qué frecuencia de derrames hash / sort en tempdb es preocupante?

Nuestra aplicación empresarial utiliza SQL Server para el almacenamiento de datos y es principalmente un sistema OLTP. Sin embargo, un componente importante de nuestra aplicación genera una carga de trabajo OLAP significativa.

Nuestra latencia de escritura en tempdb es de aproximadamente 100 ms. Esta tendencia se mantiene con el tiempo y ALLOW_SNAPSHOT_ISOLATIONse apaga . Estamos solucionando este problema preocupante y lo único interesante que hemos encontrado hasta ahora es que hay un número significativo de derrames hash y sort en tempdb. Suponemos que esto proviene de nuestra carga de trabajo OLAP.

Pregunta

¿Qué frecuencia de derrames es preocupante? ¿Alguna? ¿Cuántos derrames / segundo? Nuestros datos preliminares indican que tenemos alrededor de 2 derrames de hash por segundo y 25 derrames de clasificación por minuto.

¿Es posible que esta frecuencia de derrames pueda ser el principal culpable de nuestra latencia de escritura de alta tempdb?

Otra información

Estamos utilizando varios archivos para tempdb según lo recomendado por número de núcleos. Los archivos tempdb están en una SAN RAID 1 + 0 (con SSD de alto rendimiento) pero ese es el mismo dispositivo que los datos principales de la base de datos y los archivos de registro. Los archivos tempdb tienen un tamaño lo suficientemente grande que crecen con poca frecuencia. No estamos utilizando las marcas de seguimiento 1117 u 1118. Otra variable es que esta configuración se comparte para varias bases de datos diferentes que experimentan una carga media a alta.

Nuestra latencia de escritura de 100 ms es mucho mayor que los rangos aceptables para la latencia de escritura tempdb que hemos encontrado en MSDN, SQL Skills y otros sitios. Sin embargo, la latencia de escritura para nuestras otras bases de datos es buena (menos de 10 ms). Según otras estadísticas, parece que estamos usando tempdb en gran medida, particularmente para objetos internos. Así que estamos cavando para tratar de descubrir por qué nuestra aplicación está usando objetos internos tan fuertemente.

Tenemos problemas reales de rendimiento en nuestra plataforma que se manifiestan de diferentes maneras. Hemos estado monitoreando los contadores de rendimiento, observando las vistas de DM y analizando el comportamiento de nuestra aplicación para tratar de profundizar en las características de uso de recursos de nuestro sistema. Estamos enfocados en los derrames en este momento, ya que hemos leído que los derrames tienen un impacto negativo drástico porque se realizan en el disco en lugar de en la memoria. Y parece que tenemos una gran cantidad de derrames, pero quería obtener información sobre lo que la gente considera "alto".

¿Es posible que esta frecuencia de derrames pueda ser el principal culpable de nuestra latencia de escritura de alta tempdb?

Sí, es posible , aunque normalmente es el tamaño promedio de los derrames y su profundidad (es decir, derrames de hash recursivos, clasificaciones de múltiples pasadas) lo que importa más que la frecuencia per se.

SQL Server proporciona una amplia gama de métricas e información del DMV para ayudarlo a solucionar los diversos factores que contribuyen a la presión de tempdb, muchos de los cuales se analizan en el artículo técnico de Microsoft, "Trabajar con tempdb en SQL Server 2005" (se aplica a todas las versiones de 2005 en adelante )

Debería poder utilizar la guía y las consultas de diagnóstico contenidas en ese documento para comenzar a identificar las causas principales de cualquier presión de tempdb. No ignore, por ejemplo, la actividad de la tienda de versiones simplemente porque ALLOW_SNAPSHOT_ISOLATIONno está habilitada. Muchas características utilizan el almacén de versiones (por ejemplo, activadores, MARS, RCSI) además del aislamiento de instantáneas.

Si los derrames de clasificación y hash resultan ser significativos en un nivel alto, probablemente necesitará configurar un monitoreo específico para esto. Dependiendo un poco de su versión de SQL Server, esto no siempre es tan sencillo como cabría esperar. Para conectar los derrames de clasificación y hash con la consulta particular que los causó, se requieren notificaciones de eventos o eventos extendidos. El artículo de SolidQ, " Identificación y resolución de advertencias de clasificación " contiene detalles y algunos buenos consejos generales sobre la resolución de causas comunes.

También debe trabajar con su equipo de almacenamiento para determinar cuánto de la alta latencia es atribuible a su carga de trabajo, cuánto proviene de otros usos compartidos y qué opciones hay para la reconfiguración. Su análisis de las métricas de SQL Server ayudará a informar esta discusión, al igual que cualquier métrica que la gente de SAN pueda proporcionar.