Estimación de los requisitos de IO para el uso de ráfagas

Tenemos una aplicación que consulta una base de datos SQL periódicamente durante todo el día. Hay períodos de cero o solo actividad ligera, intercalados con solicitudes individuales de cantidades relativamente grandes de datos. Cuando llegan esas solicitudes, el objetivo principal es entregar los datos rápidamente, y el objetivo secundario es hacerlo de manera rentable. Debido a la naturaleza de la aplicación, es bastante improbable que los datos / índices se hayan almacenado en la memoria caché de la consulta anterior (diferentes usuarios, trabajando en diferentes partes de los datos).

Para un sistema que experimenta un uso relativamente constante, he escuchado la regla general para observar la longitud de la cola del disco y mantener ese número relativamente pequeño. Esto se ejecutará específicamente en AWS, donde he visto la regla general de que una longitud de cola de disco de 1 por 100 IOPS es razonable.

¿Cómo puedo estimar los requisitos de IO para dicho sistema? ¿La longitud de la cola del disco es un indicador confiable cuando se trata de consultas individuales en ráfagas? ¿Hay otras métricas que debería considerar?

sql-server performance

— Eric J.
fuente

¿Hay alguna escritura en curso, o esto es pesado?

— Jack dice que intente topanswers.xyz

@JackDouglas: Esto es 98% de lecturas. Hay un hilo de escrituras.

— Eric J.

Siguiente pregunta: ¿están dispersas las lecturas o es probable que sus "solicitudes individuales de cantidades relativamente grandes de datos" estén haciendo IO secuencial?

— Jack dice que intente topanswers.xyz

@JackDouglas: las lecturas más grandes se realizan a través de una vista indizada, de modo que la cláusula WHERE corresponde al índice, pero devuelve más datos que solo lo que está en el índice. No estoy seguro de lo que eso significa para el grado de IO secuencial. Dado que el subsistema IO subyacente es AWS EBS, no estoy seguro de cómo eso afecta el acceso físico.

— Eric J.

El subsistema IO subyacente afectará la consistencia del rendimiento , pero se preocupará por el acceso secuencial v disperso de manera similar al almacenamiento local. Esas lecturas grandes, ¿cuántos bloques distintos golpean típicamente? La exploración del índice en sí será secuencial, pero el acceso a la tabla no lo será si te he entendido correctamente hasta ahora.

— Jack dice que intente topanswers.xyz

La métrica principal que siempre he considerado para IO en SQL Server no son IOP o Longitud de cola de disco, sino rendimiento de disco (seg / lecturas y seg / escrituras). En general, las bases de datos no se refieren a cuántas operaciones puede lanzar a un disco, sino a qué tan rápido se completan esas operaciones. La regla general es tener menos de 20 ms / operación (aunque menor siempre es mejor). Más detalles se pueden encontrar en este artículo .

La longitud de la cola de disco es una estadística falsa y ya no es relevante. El problema es que el valor mide la cola para una sola unidad, pero ahora que vivimos en una era de RAID, SAN y otro almacenamiento distribuido, no hay forma de traducir adecuadamente este valor a un número significativo. Un excelente punto de partida para las métricas de rendimiento es este póster de Quest / Dell que le brinda muchas cosas y explicaciones de por qué o por qué no son importantes. No tiene que usarlos todos, pero son un comienzo.

Para probar su IO, debe comprender su carga de trabajo en su punto máximo. ¿Cuántas transacciones y cuánto se almacena en caché? A menos que sepa y haya medido esto, es realmente difícil de juzgar. Puede crear cargas de trabajo y usar herramientas como SQLIO para probar su almacenamiento, pero necesitará patrones de carga de trabajo para construir una prueba adecuada.

Finalmente, una nota sobre AWS: que yo sepa, Amazon no garantizará el rendimiento de E / S en AWS. Esto se debe principalmente a que el almacenamiento es un recurso compartido masivo y es imposible medir los patrones de usted y sus vecinos en un área particular de almacenamiento (vea el problema del vecino ruidoso ).

Mi recomendación sería asignar tanta memoria como sea posible. SQL Server solo eliminará cosas de la memoria si está bajo presión y espacio en el grupo de búferes (basado en LRU-K). Entonces, si su grupo de búferes puede almacenar la mayor parte de la base de datos en la memoria, puede mitigar parte del rendimiento explosivo. Además, considere las tácticas que pueden mantener los objetos de caché "calientes". Finalmente, vigile SQL 2014 y la nueva característica de Hekaton .

— Mike Fal
fuente

¿"SQL Server solo eliminará cosas de la memoria si está bajo presión" o en un punto de control ?

— Jack dice que intente topanswers.xyz

Checkpoint no elimina objetos del búfer, sino que escribe páginas sucias en el disco para su recuperación. Seguirá manteniendo los objetos en el grupo de búferes.

— Mike Fal

Gracias por la respuesta detallada. AWS ahora tiene una función premium llamada IOPS aprovisionados que garantiza que el número comprado de operaciones de IO por segundo se pueda realizar el 99.9% del tiempo. Creo que una operación IO se define como leer o escribir un bloque de datos de 16K.

— Eric J.

@ MikeFal: ¿Tiene alguna idea sobre la metodología de prueba específicamente para este patrón de ráfagas? ¿Solo ejecuta una sola consulta y mira los contadores en cuestión? ¿Ejecutar una serie de consultas (normalmente periódicas) una tras otra, mirando los contadores?

— Eric J.

Sí, estoy familiarizado con PIOPS. Como digo, no quiero saber cuántas operaciones se pueden realizar, quiero saber qué tan rápido son. Y esto no es algo que AWS pueda garantizar, incluso en PIOP.

— Mike Fal