Descarga de caché de SQL Server y E / S de disco

Estamos ocupados probando un sistema OLTP que hemos desarrollado en .NET 4.0 y ejecuta SQL Server 2008 R2 en la parte posterior. El sistema utiliza colas de SQL Server Service Broker, que son muy eficaces, pero estamos experimentando una tendencia peculiar durante el procesamiento.

Las solicitudes de proceso de SQL Server a una velocidad de ampollas durante 1 minuto, seguido de ~ 20 segundos de actividad de escritura en disco aumentada. El siguiente gráfico ilustra el problema.

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

Durante la resolución de problemas, intentamos lo siguiente sin ningún cambio significativo en el patrón:

• Agente SQL Server detenido.
• Eliminó casi cualquier otro proceso en ejecución (sin A / V, SSMS, VS, Windows Explorer, etc.)
• Se eliminaron todas las demás bases de datos.
• Deshabilitó todos los temporizadores de conversación (no utilizamos ningún desencadenante).
• Se alejó de un enfoque dirigido por la cola de mensajes a un diseño de monitoreo de tabla simple / crudo.
• Usó diferentes cargas, desde ligeras hasta pesadas.
• Se corrigieron todos los puntos muertos.

Parece que SQL Server podría estar acumulando su caché y escribiéndola en el disco a intervalos de tiempo específicos, pero no puedo encontrar nada en línea que respalde esta teoría.

A continuación, planeo trasladar la solución a nuestro entorno de prueba dedicado para ver si puedo replicar el problema. Cualquier ayuda en el ínterin sería muy apreciada.

Actualización 1 Según lo solicitado, adjunto un gráfico que incluye las páginas de punto de verificación / seg. , La expectativa de vida útil de la página y algunos contadores de latencia de disco.

Parece que el punto de control (línea azul claro) es la causa del rendimiento reducido (línea amarilla) que estamos observando. ^

La latencia del disco permanece relativamente constante durante el procesamiento y la expectativa de vida de la página no parece tener ningún efecto notable. También ajustamos la cantidad de ram disponible para SQL Server, que tampoco tuvo un gran efecto. Cambiar el modelo de recuperación de SIMPLEa FULLtambién hizo poca diferencia.

Actualización 2 Al cambiar el "Intervalo de recuperación" de la siguiente manera, hemos logrado reducir el intervalo en el que ocurren los puntos de control:

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

Sin embargo, no estoy seguro de si esto es una mala práctica.

Otros ya han señalado al culpable: SQL Server acumula actualizaciones en la memoria (en el grupo de búferes) y solo las elimina periódicamente (en los puntos de control). Las dos opciones sugeridas (-k e intervalo de punto de control) son complementarias:

• -k hará que el punto de control produzca solicitudes de E / S menos agresivas y dure más
• reducir el intervalo de recuperación hará que el punto de control se inicie con más frecuencia

Pero no respondí solo para regurgitar los buenos comentarios que recibiste hasta ahora :)

Lo que está viendo es, desafortunadamente, un comportamiento muy típico del procesamiento en cola . Ya sea que use colas de Service Broker u opte por usar tablas como aproximaciones de colas , el sistema es muy propenso a este tipo de comportamiento. Esto se debe a que el procesamiento basado en la cola es pesado, incluso más pesado que el procesamiento OLTP. Tanto en cola y dequeue primitivas son las operaciones de escritura y hay operaciones casi sin leer. En pocas palabras, el procesamiento de la cola generará la mayor cantidad de escrituras (= páginas más sucias y más registros) en comparación con cualquier otra carga de trabajo, incluso OLTP (es decir, carga de trabajo similar a TPC-C ).

Muy importante, las escrituras de una carga de trabajo en cola siguen un patrón de inserción / eliminación: cada fila insertada se elimina muy rápidamente. Es importante distinguirlo de un patrón de solo agregado de una carga de trabajo de inserción pesada (ETL). Básicamente, está alimentando la tarea de limpieza de fantasmas con una comida completa, y puede superarla fácilmente. Piensa en lo que eso significa:

• enqueue es un inserto, creará una página sucia
• Dequeue es una eliminación, ensuciará la misma página nuevamente (puede ser afortunado y atrapar la página antes del punto de control, por lo que evitará doble descarga, pero solo si tiene suerte)
• la limpieza fantasma limpiará la página, volviéndola sucia

Sí, realmente significa que puede terminar escribiendo una página tres veces en el disco, en tres solicitudes de E / S diferentes, para cada mensaje que procese (el peor de los casos). Y también significa que la E / S aleatoria de los puntos de verificación será realmente aleatoria ya que el punto de escritura de la página será visitado nuevamente por esos cabezales móviles entre dos puntos de verificación (en comparación con muchas cargas de trabajo OLTP tienden a agrupar las escrituras en algunos 'puntos calientes', no colas ...)

Entonces tienes estos tres puntos de escritura, corriendo para marcar la misma página sucia una y otra vez. Y eso es antes de considerar cualquier división de página, cuyo procesamiento de cola también puede ser propenso debido al orden de inserción de la clave. En comparación, las cargas de trabajo OLTP 'típicas' tienen una relación de lectura / escritura mucho más equilibrada y las escrituras OLTP se distribuyen a través de inserciones / actualizaciones / eliminaciones, a menudo con actualizaciones (cambios de 'estado') e inserciones que toman la mayor parte. Las escrituras de procesamiento de cola se insertan / eliminan exclusivamente con, por definición, división 50/50.

Algunas consecuencias siguen:

• El punto de control se convierte en un tema muy candente (ya no es una sorpresa para ti)
• Verá una gran fragmentación (la fragmentación per-se no importará mucho ya que no va a hacer escaneos de rango, pero su eficiencia de E / S se ve afectada y la limpieza fantasma tiene más que funcionar, ralentizándola aún más)
• Su rendimiento de E / S aleatorio de almacenamiento MDF será su cuello de botella

Mi recomendación viene en 3 letras: S, S y D. Mueva su MDF a un almacenamiento que pueda manejar IO aleatorio rápido. SSD Fusion-IO si tienes el dinero. Desafortunadamente, este es uno de esos síntomas que no se pueden resolver con RAM más barata ...

Editar:

Como Mark señala, tiene dos discos lógicos respaldados por un disco físico. Tal vez trató de seguir las mejores prácticas y dividir el inicio de sesión en D: y los datos en C: pero desgraciadamente es en vano, C y D son el mismo disco. Entre los puntos de control, se logra un rendimiento secuencial, pero tan pronto como se inicia el punto de control, los cabezales del disco comienzan a moverse y su rendimiento de registro se colapsa, eliminando todo el rendimiento de la aplicación. Asegúrese de separar el registro de la base de datos para que no se vea afectado por los datos IO (disco separado).