Azure Premium Storage: diseño para un alto rendimiento
Se aplica a: ✔️ Máquinas virtuales Linux ✔️ Máquinas virtuales Windows ✔️ Conjuntos de escalado flexibles ✔️ Conjuntos de escalado uniformes
Este artículo proporciona instrucciones para crear aplicaciones de alto rendimiento con Azure Premium Storage. Puede usar las instrucciones proporcionadas en este documento junto con los procedimientos recomendados de rendimiento aplicables a las tecnologías usadas por la aplicación. Para ilustrar las directrices, se usa SQL Server ejecutado en Premium Storage como ejemplo en este documento.
Si bien en este artículo se tratan los escenarios de rendimiento de la capa de almacenamiento, deberá optimizar la capa de la aplicación. Por ejemplo, si hospeda una granja de SharePoint en Premium Storage, puede usar los ejemplos de SQL Server de este artículo para optimizar el servidor de bases de datos. También puede optimizar el servidor web y el servidor de aplicaciones de la granja de SharePoint para obtener el máximo rendimiento.
Este artículo ayuda a responder a las siguientes preguntas habituales acerca de cómo optimizar el rendimiento de las aplicaciones en Premium Storage:
- ¿Cómo se puede medir el rendimiento de las aplicaciones?
- ¿Por qué no ve el alto rendimiento previsto?
- ¿Qué factores influyen en el rendimiento de las aplicaciones en Premium Storage?
- ¿Cómo influyen estos factores en el rendimiento de las aplicaciones en Premium Storage?
- ¿Cómo se pueden optimizar las operaciones de entrada y salida por segundo (IOPS), el ancho de banda y la latencia?
Se proporcionan estas directrices específicamente para Premium Storage porque las cargas de trabajo que se ejecutan en Premium Storage dependen mucho del rendimiento. Se proporcionan ejemplos cuando corresponda. También puede aplicar algunas de estas instrucciones a las aplicaciones que se ejecutan en máquinas virtuales de una infraestructura como servicio (IaaS) con discos de Standard Storage.
Nota:
A veces, lo que parece ser un problema de rendimiento del disco es realmente un cuello de botella de red. En estos casos, debería optimizarse el rendimiento de la red.
Si quiere hacer pruebas comparativas de su disco, consulte los artículos siguientes:
- Para Linux: Ejecución de un banco de pruebas de la aplicación en Azure Disk Storage.
- Para Windows: pruebas comparativas de un disco
Si la máquina virtual admite redes aceleradas, asegúrese de que esté habilitada. Si no lo está, puede habilitarla en máquinas virtuales ya implementadas, tanto en Windows como en Linux.
Antes de comenzar, si es la primera vez que usa Premium Storage, lea antes los artículos Selección de un tipo de disco para máquinas virtuales IaaS de Azure y Objetivos de escalabilidad de las cuentas de almacenamiento de blob en páginas Premium.
Indicadores del rendimiento de las aplicaciones
Se evalúa si una aplicación funciona bien o no mediante el uso de indicadores de rendimiento como los siguientes:
- La rapidez con la que una aplicación procesa una solicitud de usuario.
- La cantidad de datos que procesa una aplicación por solicitud.
- El número de solicitudes que procesa una aplicación en un período de tiempo específico.
- Cuánto tiempo tiene que esperar un usuario para obtener una respuesta después de enviar su solicitud.
Los términos técnicos para estos indicadores de rendimiento son IOPS, latencia y rendimiento o ancho de banda.
En esta sección se describen los indicadores de rendimiento comunes en el contexto de Premium Storage. En la sección Lista de comprobación del rendimiento de las aplicaciones para los discos aprenderá a medir estos indicadores de rendimiento de la aplicación. Más adelante, en Optimización del rendimiento de las aplicaciones, obtendrá información sobre los factores que afectan a estos indicadores de rendimiento, así como recomendaciones para optimizarlos.
E/S
IOPS es el número de solicitudes que la aplicación envía a los discos de almacenamiento en un segundo. Una operación de entrada y salida puede ser de lectura o escritura, secuencial o aleatoria. Las aplicaciones de procesamiento de transacciones en línea (OLTP), como un sitio web de venta directa en línea, necesitan procesar muchas solicitudes de usuario simultáneas inmediatamente. Las solicitudes de usuario son transacciones de base de datos de inserción y actualización intensivas, que la aplicación debe procesar rápidamente. Por este motivo, las aplicaciones OLTP requieren IOPS muy altas.
Las aplicaciones OLTP controlan millones de solicitudes de E/S pequeñas y aleatorias. Si tiene este tipo de aplicación, debe diseñar la infraestructura de aplicaciones para optimizar la IOPS. Para obtener más información sobre todos los factores que se deben tener en cuenta para obtener una IOPS elevada, consulte Optimización del rendimiento de las aplicaciones.
Cuando conecte un disco de Almacenamiento premium a la máquina virtual a gran escala, Azure aprovisiona automáticamente un número garantizado de IOPS según la especificación del disco. Por ejemplo, un disco P50 aprovisiona 7500 IOPS. Cada tamaño de máquina virtual a gran escala también tiene un límite de IOPS específico que puede admitir. Por ejemplo, una VM GS5 estándar tiene un límite de 80 000 IOPS.
Throughput
El rendimiento o ancho de banda es la cantidad de datos que la aplicación envía a los discos de almacenamiento en un intervalo especificado. Si la aplicación está realizando operaciones de entrada y salida con tamaños de unidad de E/S grandes, requiere un alto rendimiento. Las aplicaciones de almacenamiento de datos tienden a emitir operaciones con un uso intensivo de análisis que acceden a grandes porciones de datos a la vez y suelen llevar a cabo operaciones masivas. En otras palabras, estas aplicaciones requieren un mayor rendimiento. Si tiene este tipo de aplicación, debe diseñar su infraestructura para optimizar el rendimiento. En la sección siguiente se describen los factores que se deben ajustar para lograr esta optimización.
Al conectar un disco de Premium Storage a una máquina virtual a gran escala, Azure aprovisiona el rendimiento según esa especificación de disco. Por ejemplo, un disco P50 aprovisiona un rendimiento de disco de 250 MB/s. Cada tamaño de máquina virtual a gran escala también tiene un límite de rendimiento específico que puede admitir. Por ejemplo, la máquina virtual GS5 estándar tiene un rendimiento máximo de 2000 MB/s.
Hay una relación entre el rendimiento y las IOPS, tal como se muestra en la siguiente fórmula.
Es importante determinar los valores óptimos de rendimiento y de IOPS que requiere una aplicación. Si intenta optimizar uno, el otro también se verá afectado. Para obtener más información sobre la optimización de las IOPS y el rendimiento, consulte Optimización del rendimiento de las aplicaciones.
Latencia
La latencia es el tiempo que tarda una aplicación en recibir una sola solicitud, enviarla a los discos de almacenamiento y enviar la respuesta al cliente. La latencia es una medida crítica del rendimiento de una aplicación, además de las IOPS y del rendimiento. La latencia de un disco de almacenamiento premium es el tiempo que tarda en recuperar la información de una solicitud y comunicarla de nuevo a la aplicación. Premium Storage proporciona latencias constantemente bajas. Los discos Premium están diseñados para proporcionar latencias de milisegundos de un solo dígito en la mayoría de las operaciones de E/S. Si habilita el almacenamiento en caché de host ReadOnly en discos de almacenamiento premium, puede obtener una latencia de lectura mucho menor. Para obtener más información sobre el almacenamiento en caché de discos, vea Almacenamiento en caché de discos.
Al optimizar la aplicación para obtener IOPS y un rendimiento más elevados, afecta a la latencia de la aplicación. Después de ajustar el rendimiento de las aplicaciones, se evalúa la latencia de la aplicación para evitar un comportamiento inesperado con alta latencia.
Algunas operaciones de plano de control en discos administrados podrían mover el disco de una ubicación de almacenamiento a otra. El movimiento del disco entre ubicaciones de almacenamiento se orquesta mediante la copia en segundo plano de los datos, que puede tardar varias horas. Normalmente, suele tardar menos de 24 horas en función de la cantidad de datos de los discos. Durante ese tiempo, la aplicación puede experimentar una latencia de lectura más alta de lo habitual, ya que algunas lecturas pueden redirigirse a la ubicación original y pueden tardar más.
Durante una copia en segundo plano, no hay ningún efecto en la latencia de escritura para la mayoría de los tipos de disco. En el caso de los discos SSD prémium v2 y Ultra, si el disco tiene un tamaño de sector de 4000, experimenta una mayor latencia de lectura. Si el disco tiene un tamaño de sector de 512e, experimenta una mayor latencia de lectura y escritura.
Las siguientes operaciones del plano de control pueden mover el disco entre ubicaciones de almacenamiento y provocar una mayor latencia:
- Actualizar el tipo de almacenamiento.
- Asociar o desasociar un disco de una VM a otra.
- Crear un disco administrado a partir de un VHD.
- Crear un disco administrado a partir de una instantánea.
- Convertir discos no administrados en discos administrados.
Lista de comprobación del rendimiento de las aplicaciones para los discos
El primer paso para diseñar aplicaciones de alto rendimiento que se ejecutan en Premium Storage es entender los requisitos de rendimiento de las aplicaciones. Después de reunir los requisitos de rendimiento, puede optimizar la aplicación para lograr un rendimiento óptimo.
En la sección anterior se han explicado los indicadores de rendimiento comunes: IOPS, rendimiento y latencia. Debe identificar cuál de estos indicadores de rendimiento son fundamentales para que la aplicación proporcione la experiencia de usuario deseada. Por ejemplo, una IOPS alta es más importante para las aplicaciones OLTP que procesan millones de transacciones en un segundo. Un rendimiento alto es fundamental para las aplicaciones de almacenamiento de datos que procesan grandes cantidades de datos en un segundo. Una latencia extremadamente baja es fundamental para las aplicaciones en tiempo real, como sitios web de streaming de vídeo en directo.
A continuación, mida los requisitos para obtener el máximo rendimiento de sus aplicaciones a lo largo de toda su duración. Use la siguiente lista de comprobación de ejemplo como punto de partida. Registre los requisitos para obtener el máximo rendimiento durante períodos de carga de trabajo normales, pico y valle. Al identificar los requisitos para todos los niveles de carga de trabajo, puede determinar los requisitos de rendimiento generales de la aplicación.
Por ejemplo, la carga de trabajo normal de un sitio web de comercio electrónico son las transacciones atendidas durante la mayoría de los días en un año. La carga de trabajo máxima del sitio web son las transacciones atendidas durante las temporadas de vacaciones o eventos de ventas especiales. La carga de trabajo máxima normalmente se experimenta durante un período limitado, pero puede que la aplicación deba escalar su funcionamiento normal de dos o más veces. Descubra los requisitos de percentil 50, percentil 90 y percentil 99. Esta información ayuda a filtrar los valores atípicos en los requisitos de rendimiento, por lo que puede centrar sus esfuerzos en optimizar para los valores correctos.
Lista de comprobación de requisitos de rendimiento de las aplicaciones
Requisitos de rendimiento | Percentil 50 | Percentil 90 | Percentil 99 |
---|---|---|---|
Número máximo de transacciones por segundo | |||
Porcentaje de operaciones de lectura | |||
Porcentaje de operaciones de escritura | |||
Porcentaje de operaciones aleatorias | |||
Porcentaje de operaciones secuenciales | |||
Tamaño de la solicitud de E/S | |||
Rendimiento medio | |||
Rendimiento máximo | |||
Latencia mínima | |||
Latencia media | |||
CPU máxima | |||
Promedio de CPU | |||
Memoria máxima | |||
Promedio de memoria | |||
Profundidad de la cola |
Nota:
Considere la posibilidad de escalar estos números en función del crecimiento futuro previsto de la aplicación. Es buena idea para planificar el crecimiento antes de tiempo, porque podría ser más difícil cambiar la infraestructura para mejorar el rendimiento más adelante.
Si tiene una aplicación existente y desea cambiar a Premium Storage, cree primero la lista de comprobación anterior para la aplicación existente. A continuación, cree un prototipo de la aplicación en Premium Storage y diseñe la aplicación de acuerdo con las directrices descritas en Optimización del rendimiento de las aplicaciones. En el siguiente artículo se describen las herramientas que puede usar para recopilar las mediciones de rendimiento.
Contadores para medir los requisitos de rendimiento de las aplicaciones
La mejor forma de medir los requisitos de rendimiento de las aplicaciones es usar las herramientas de supervisión PerfMon
que proporciona el sistema operativo del servidor. Puede usar PerfMon
para Windows y iostat
para Linux. Estas herramientas capturan contadores correspondientes a cada medida explicada en la sección anterior. Debe capturar los valores de estos contadores cuando la aplicación funciona con cargas de trabajo normales, pico y valle.
Los contadores PerfMon
están disponibles para el procesador y la memoria, así como en cada disco lógico y físico del servidor. Al usar discos de Almacenamiento premium con una máquina virtual, los contadores del disco físico son para cada disco de Almacenamiento premium y los contadores del disco lógico son para cada volumen creado en los discos de Almacenamiento premium. Debe capturar los valores de los discos que hospedan la carga de trabajo de la aplicación. Si hay una asignación uno a uno entre los discos lógicos y físicos, puede hacer referencia a los contadores del disco físico. De lo contrario, consulte los contadores del disco lógico.
En Linux, el comando iostat
genera un informe de uso de CPU y disco. El informe de uso del disco proporciona estadísticas por cada dispositivo físico o partición. Si tiene un servidor de bases de datos con sus datos y registros en discos independientes, recopile estos datos para ambos discos. En la tabla siguiente se describen los contadores para discos, procesadores y memoria.
Contador | Descripción | PerfMon | iostat |
---|---|---|---|
IOPS o transacciones por segundo | Número de solicitudes de E/S emitidas en el disco de almacenamiento por segundo | Lecturas de disco por segundo Escrituras en disco por segundo |
tps r/s w/s |
Escrituras y lecturas de disco | Porcentaje de operaciones de lectura y escritura efectuadas en el disco | % de tiempo de lectura de disco % de tiempo de escritura en disco |
r/s w/s |
Throughput | Cantidad de datos que se leen o escriben en el disco por segundo | Bytes de lectura de disco por segundo Bytes de escritura en disco por segundo |
kB_read/s kB_wrtn/s |
Latencia | Tiempo total para efectuar una solicitud de E/S del disco | Promedio de segundos de disco/lectura Promedio de segundos de disco/escritura |
await svctm |
Tamaño de E/S | El tamaño de las solicitudes de E/S a los discos de almacenamiento | Promedio de bytes de disco/lectura Promedio de bytes de disco/escritura |
avgrq-sz |
Profundidad de la cola | Número de solicitudes de E/S pendientes de lectura o escritura en el disco de almacenamiento | Longitud actual de la cola de disco | avgqu-sz |
Memoria máxima | Cantidad de memoria necesaria para ejecutar la aplicación sin problemas | % de bytes confirmados en uso | Use vmstat |
CPU máxima | Cantidad de CPU necesaria para ejecutar la aplicación sin problemas | % de tiempo de procesador | %util |
Obtenga más información sobre iostat y PerfMon.
Optimización del rendimiento de las aplicaciones
Los principales factores que influyen en el rendimiento de una aplicación que se ejecuta en Premium Storage son la naturaleza de las solicitudes de E/S, el tamaño de la máquina virtual, el tamaño del disco, el número de discos, el almacenamiento en caché de disco, el multithreading y la profundidad de la cola. Puede controlar algunos de estos factores con mecanismos proporcionados por el sistema.
Es posible que la mayoría de las aplicaciones no le den ninguna opción para modificar directamente el tamaño de E/S y la profundidad de la cola. Por ejemplo, si usa SQL Server, no puede elegir la profundidad de la cola ni el tamaño de E/S. SQL Server selecciona los valores de tamaño de E/S y profundidad de la cola óptimos para obtener el máximo rendimiento. Es importante comprender los efectos de ambos tipos de factores en rendimiento de su aplicación para poder aprovisionar los recursos adecuados para satisfacer las necesidades de rendimiento.
En esta sección, consulte la lista de comprobación de los requisitos de la aplicación que creó para averiguar la cantidad que necesita para optimizar el rendimiento de las aplicaciones. En función de la lista de comprobación, puede determinar qué factores de esta sección debe ajustar.
Para ver los efectos de cada factor en el rendimiento de las aplicaciones, ejecute las herramientas de pruebas comparativas en la configuración de su aplicación. Para conocer los pasos para ejecutar las herramientas de pruebas comparativas comunes en las máquinas virtuales de Windows y de Linux, vea los artículos sobre pruebas comparativas al final de este documento.
Optimización de IOPS, rendimiento y latencia de un vistazo
En la tabla siguiente se resumen los factores de rendimiento y los pasos necesarios para optimizar la IOPS, el rendimiento y la latencia. Las secciones que siguen a este resumen describen cada factor con mayor profundidad.
Para obtener más información sobre los tamaños de máquina virtual y la IOPS, el rendimiento y la latencia disponibles para cada tipo de máquina virtual, vea Tamaños de máquinas virtuales en Azure.
Factores de rendimiento | E/S | Throughput | Latencia |
---|---|---|---|
Escenario de ejemplo | Aplicación OLTP empresarial que requiere una tasa muy alta de transacciones por segundo. | Aplicación de Almacenamiento de datos de empresa que procesa grandes cantidades de datos. | Aplicaciones casi en tiempo real que requieren respuestas instantáneas a solicitudes de usuario, como juegos en línea. |
Factores de rendimiento | |||
Tamaño de E/S | Un tamaño de E/S menor produce una mayor IOPS. | El tamaño de E/S más grande produce un mayor rendimiento. | |
Tamaño de VM | Use un tamaño de máquina virtual que ofrezca una IOPS mayor que los requisitos de la aplicación. | Use un tamaño de máquina virtual con un límite de rendimiento mayor que los requisitos de la aplicación. | Use un tamaño de máquina virtual que ofrezca una escala de límites mayor que los requisitos de la aplicación. |
Tamaño del disco | Use un tamaño de disco que ofrezca una IOPS mayor que los requisitos de la aplicación. | Use un tamaño de disco con un límite de rendimiento mayor que los requisitos de la aplicación. | Use un tamaño de disco que ofrezca una escala de límites mayor que los requisitos de la aplicación. |
Límites de escala de las máquinas virtuales y los discos | El límite de IOPS del tamaño de la máquina virtual elegido debe ser mayor que la IOPS total controlada por los discos de almacenamiento conectados. | El límite de rendimiento del tamaño de la máquina virtual elegido debe ser mayor que el rendimiento total controlado por los discos de Premium Storage conectados. | Los límites de la escala del tamaño de la máquina virtual elegidos deben ser mayores que los límites de escala total de los discos de Premium Storage conectados. |
Almacenamiento en caché de disco | Habilite la caché ReadOnly en los discos de Premium Storage con operaciones intensivas de lectura para obtener una mayor IOPS de lectura. | Habilite la caché ReadOnly en los discos de Premium Storage con operaciones intensivas de lectura para obtener latencias de lectura muy bajas. | |
Seccionamiento del disco | Use varios discos y secciónelos conjuntamente para conseguir un límite de IOPS y rendimiento combinado superior. El límite combinado por máquina virtual debe ser mayor que los límites combinados de los discos premium conectados. | ||
Stripe size (Tamaño de las franjas) | Un menor tamaño de franja para un patrón de E/S pequeño y aleatorio visto en las aplicaciones OLTP. Por ejemplo, puede usar un tamaño de franja de 64 KB para una aplicación OLTP de SQL Server. | Un mayor tamaño de franja para un patrón de E/S grande y secuencial visto en las aplicaciones de almacenamiento de datos. Por ejemplo, puede usar un tamaño de franja de 256 KB para una aplicación de almacenamiento de datos de SQL Server. | |
Subprocesamiento múltiple | Use el multithreading para insertar un mayor número de solicitudes en Premium Storage, lo que dará lugar a una mayor IOPS y rendimiento. Por ejemplo, en SQL Server establezca un valor MAXDOP alto para asignar más CPU a SQL Server. | ||
Profundidad de la cola | Una profundidad de la cola mayor produce una IOPS mayor. | Una profundidad de la cola mayor produce un mayor rendimiento. | Una profundidad de la cola menor produce latencias más bajas. |
Naturaleza de las solicitudes de E/S
Una solicitud de E/S es una unidad de operación de entrada y salida que lleva a cabo la aplicación. La identificación de la naturaleza de las solicitudes de E/S, aleatorias o secuenciales, lectura o escritura, pequeñas o grandes, ayuda a determinar los requisitos de rendimiento de la aplicación. Es importante comprender la naturaleza de las solicitudes de E/S para tomar las decisiones correctas a la hora de diseñar la infraestructura de las aplicaciones. Las E/S deben distribuirse uniformemente para lograr el mejor rendimiento posible.
El tamaño de E/S es uno de los factores más importantes. El tamaño de E/S es el tamaño de la solicitud de operación de entrada/salida generada por la aplicación. El tamaño de E/S afecta significativamente al rendimiento, especialmente en las IOPS y el ancho de banda que puede alcanzar la aplicación. La fórmula siguiente muestra la relación entre IOPS, tamaño de E/S y ancho de banda/rendimiento.
Algunas aplicaciones permiten modificar su tamaño de E/S, mientras que otras aplicaciones no. Por ejemplo, SQL Server determina el tamaño de E/S óptimo en sí; no proporciona a los usuarios ningún botón para cambiarlo. Por otro lado, Oracle proporciona un parámetro llamado DB_BLOCK_SIZE, que puede usar para configurar el tamaño de la solicitud de E/S de la base de datos.
Si usa una aplicación que no permite cambiar el tamaño de E/S, use las directrices de este artículo para optimizar el KPI de rendimiento que es más importante para su aplicación. Por ejemplo:
- Una aplicación OLTP genera millones de solicitudes de E/S pequeñas y aleatorias. Para controlar estos tipos de solicitudes de E/S, debe diseñar la infraestructura de la aplicación para obtener una mayor IOPS.
- Una aplicación de almacenamiento de datos genera solicitudes de E/S grandes y secuenciales. Para controlar estos tipos de solicitudes de E/S, debe diseñar la infraestructura de la aplicación para obtener el mayor ancho de banda o el rendimiento.
Si usa una aplicación que le permite cambiar el tamaño de E/S, use esta regla general para el tamaño de E/S, además otras directrices de rendimiento:
- Un tamaño de E/S menor para obtener una mayor IOPS. Por ejemplo, 8 KB para una aplicación OLTP.
- Un tamaño de E/S mayor para obtener un mayor ancho de banda y rendimiento. Por ejemplo, 1024 KB para una aplicación de almacenamiento de datos.
Este es un ejemplo de cómo calcular la IOPS y el ancho de banda y el rendimiento de la aplicación.
Considere la posibilidad de usar una aplicación que use un disco P30. El máximo rendimiento/ancho de banda e IOPS que un disco P30 puede lograr es 200 MB/s y 5000 IOPS, respectivamente. Si la aplicación necesita el número máximo de IOPS del disco P30 y usa un tamaño de E/S más pequeño (por ejemplo, 8 KB), el ancho de banda resultante que puede obtener es de 40 MB/s. Si la aplicación necesita el rendimiento o ancho de banda máximo de un disco P30 y usa un tamaño de E/S mayor (por ejemplo, 1024 KB), la IOPS resultante es menor, como 200 IOPS.
Debe ajustar el tamaño de E/S para que cumpla los requisitos de IOPS y ancho de banda/rendimiento de la aplicación. En la siguiente tabla se resumen los distintos tamaños de E/S, así como sus IOPS y rendimiento correspondientes para un disco P30.
Requisito de la aplicación | Tamaño de E/S | E/S | Rendimiento/ancho de banda |
---|---|---|---|
Número máximo de IOPS | 8 KB | 5\.000 | 40 MB/s |
Rendimiento máximo | 1024 KB | 200 | 200 MB/s |
Rendimiento máximo + IOPS elevada | 64 KB | 3\.200 | 200 MB/s |
IOPS máxima + rendimiento elevado | 32 KB | 5\.000 | 160 MB/s |
Para obtener una IOPS y un ancho de banda mayores que el valor máximo de un solo disco de Premium Storage, use varios discos premium seccionados conjuntamente. Por ejemplo, puede seccionar dos discos P30 para obtener una IOPS combinada de 10 000 IOPS o un rendimiento combinado de 400 MB/s. Como se explica en la sección siguiente, debe usar un tamaño de máquina virtual que admita la IOPS y el rendimiento de disco combinados.
Nota:
A medida que aumenta la IOPS o el rendimiento, el otro también aumentará. Asegúrese de no alcanzar los límites de rendimiento o IOPS del disco o de la máquina virtual al aumentar cualquiera de ellos.
Para ver los efectos del tamaño de E/S en el rendimiento de las aplicaciones, puede ejecutar las herramientas de pruebas comparativas en la máquina virtual y los discos. Cree varias ejecuciones de pruebas y use un tamaño de E/S diferente para cada ejecución para ver la repercusión. Para obtener más información, consulte los artículos de pruebas comparativas al final de este documento.
Tamaños de máquina virtual a gran escala
Al empezar a diseñar una aplicación, una de las primeras cosas que hay que hacer es elegir una máquina virtual para hospedar la aplicación. Premium Storage viene con tamaños de máquina virtual a gran escala que pueden ejecutar aplicaciones que requieren una mayor capacidad de proceso y un alto rendimiento de E/S del disco local. Estas máquinas virtuales proporcionan procesadores más rápidos, una mayor proporción de memoria a núcleo y una unidad de estado sólido (SSD) para el disco local. Algunos ejemplos de máquinas virtuales a gran escala que admiten Premium Storage son las de las series DS y GS.
Las máquinas virtuales a gran escala están disponibles en distintos tamaños con un número diferente de núcleos de CPU, memoria, sistema operativo y tamaño del disco temporal. Cada tamaño de máquina virtual también tiene un número máximo de discos de datos que se puede conectar a la máquina virtual. El tamaño de máquina virtual seleccionado afecta al procesamiento, la memoria y la capacidad de almacenamiento disponibles para la aplicación. También afecta al proceso y los costos de almacenamiento. Por ejemplo, las especificaciones siguientes son para el tamaño de máquina virtual más grande de una serie DS y de una serie GS.
Tamaño de VM | Núcleos de CPU | Memoria | Tamaños de disco de VM | Número máximo de discos de datos | Tamaño de memoria caché | E/S | Límites de E/S de caché de ancho de banda |
---|---|---|---|---|---|---|---|
Standard_DS14 | 16 | 112 GB | SO = 1023 GB SSD Local = 224 GB |
32 | 576 GB | 50.000 E/S por segundo 512 MB/s |
4000 IOPS y 33 MB/s |
Standard_GS5 | 32 | 448 GB | SO = 1023 GB SSD Local = 896 GB |
64 | 4224 GB | 80.000 E/S por segundo 2000 MB/s |
5000 IOPS y 50 MB/s |
Para ver una lista completa de todos los tamaños disponibles de máquina virtual de Azure, consulte Tamaños de las máquinas virtuales en Azure. Elija un tamaño de máquina virtual que puede cumplir y escale a los requisitos de rendimiento de las aplicaciones que desee. Tenga en cuenta también que debe seguir las siguientes consideraciones importantes a la hora de elegir los tamaños de las máquinas virtuales.
Límites de escalado
Los límites máximos de IOPS por máquina virtual y por disco son diferentes e independientes entre sí. Asegúrese de que la aplicación mantiene la IOPS dentro de los límites de la máquina virtual y los discos premium conectados a ella. En caso contrario, el rendimiento de las aplicaciones experimentará una limitación.
Por ejemplo, suponga que el requisito de la aplicación es un máximo de 4.000 IOPS. Para lograr este nivel, debe aprovisionar un disco P30 en una máquina virtual DS1. El disco P30 puede proporcionar hasta 5.000 IOPS. Sin embargo, la máquina virtual DS1 está limitada a 3.200 IOPS. Por lo tanto, el rendimiento de la aplicación está restringido por el límite de máquina virtual a 3200 IOPS y el rendimiento disminuirá. Para evitar esta situación, elija un tamaño de máquina virtual y de disco que cumplan los requisitos de la aplicación.
Costo de operación
En muchos casos, es posible que el costo general de operación con Premium Storage sea inferior al uso de Standard Storage.
Por ejemplo, considere una aplicación que requiere más de 16.000 IOPS. Para conseguir este rendimiento, necesita una VM IaaS de Azure Standard_D14, que puede proporcionar una IOPS máxima de 16 000 con 32 discos de 1 TB de almacenamiento estándar. Cada disco de almacenamiento estándar de 1 TB puede alcanzar un máximo de 500 IOPS.
- El costo mensual estimado de esta máquina virtual es de 1570 USD.
- El costo mensual de 32 discos de Standard Storage es de 1638 USD.
- El costo mensual total estimado es de 3208 USD.
Si hospeda la misma aplicación en Premium Storage, necesita un tamaño de máquina virtual menor y menos discos de Premium Storage, lo que reduce el costo total. Una máquina virtual Standard_DS13 puede cumplir los requisitos de 16 000 IOPS mediante cuatro discos P30. La máquina virtual DS13 tiene un máximo de 25 600 IOPS y cada disco P30 tiene un máximo de 5000 IOPS. En general, esta configuración puede lograr 5.000 x 4 = 20.000 IOPS.
- El costo mensual estimado de esta máquina virtual es de 1003 USD.
- El costo mensual de cuatro discos P30 de Premium Storage es de 544,34 USD.
- El costo mensual total estimado es de 1544 USD.
La tabla siguiente resume el análisis de costos de este escenario para Standard Storage y Premium Storage.
Coste mensual | Estándar | Premium |
---|---|---|
Costo de máquina virtual al mes | 1570,58 USD (Standard_D14) | 1003,66 USD (Standard_DS13) |
Costo mensual de los discos | 1638,40 USD (32 discos x 1 TB) | 544,34 USD (4 discos x P30) |
Costo mensual total | 3\.208,98 USD | 1\.544,34 USD |
Distribuciones de Linux
Con Premium Storage obtendrá el mismo nivel de rendimiento para las máquinas virtuales de Windows y de Linux. Se admiten muchos tipos de distribuciones de Linux. Para obtener más información, consulte Distribuciones de Linux aprobadas en Azure.
Las distintas distribuciones son más adecuadas para diferentes tipos de cargas de trabajo. Verá diferentes niveles de rendimiento según la distribución en la que se ejecuta la carga de trabajo. Pruebe las distribuciones de Linux con su aplicación y elija la que mejor se adapte.
Cuando ejecute Linux con Premium Storage, compruebe las actualizaciones más recientes acerca de los controladores necesarios para garantizar un alto rendimiento.
Tamaños de disco de Premium Storage
Premium Storage ofrece varios tamaños para que pueda elegir el que mejor se adapte a sus necesidades. Cada tamaño de disco tiene un límite de escala diferente de IOPS, ancho de banda y almacenamiento. Elija el tamaño de disco de Premium Storage adecuado según los requisitos de la aplicación y el tamaño de la máquina virtual a gran escala. En la tabla siguiente se muestran los tamaños de disco y sus capacidades. Los tamaños de disco P4, P6, P15, P60, P70 y P80 solo se admiten actualmente para discos administrados.
Tamaños de SSD Premium | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tamaño de disco en GiB | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 | 2 048 | 4 096 | 8192 | 16 384 | 32 767 |
IOPS base aprovisionadas por disco | 120 | 120 | 120 | 120 | 240 | 500 | 1 100 | 2,300 | 5\.000 | 7 500 | 7 500 | 16 000 | 18 000 | 20.000 |
**IOPS aprovisionadas expandidas por disco | N/D | N/D | N/D | N/D | N/D | N/D | N/D | N/D | 8,000 | 16 000 | 20.000 | 20.000 | 20.000 | 20.000 |
Rendimiento base aprovisionado por disco | 25 MB/s | 25 MB/s | 25 MB/s | 25 MB/s | 50 MB/s | 100 MB/s | 125 MB/s | 150 MB/s | 200 MB/s | 250 MB/s | 250 MB/s | 500 MB/s | 750 MB/s | 900 MB/s |
**Rendimiento aprovisionado ampliado por disco | N/D | N/D | N/D | N/D | N/D | N/D | N/D | N/D | 300 MB/s | 600 MB/s | 900 MB/s | 900 MB/s | 900 MB/s | 900 MB/s |
Máximo de IOPS de ráfaga por disco | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 30 000* | 30 000* | 30 000* | 30 000* | 30 000* | 30 000* |
Capacidad de proceso máximo de ráfaga por disco | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 1000 MB/s | 1000 MB/s | 1000 MB/s | 1000 MB/s | 1000 MB/s | 1000 MB/s |
Duración máxima de ráfaga | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | Sin límite* | Sin límite* | Sin límite* | Sin límite* | Sin límite* | Sin límite* |
Apto para reserva | No | N.º | N.º | N.º | N.º | N.º | N.º | No | Sí, hasta un año | Sí, hasta un año | Sí, hasta un año | Sí, hasta un año | Sí, hasta un año | Sí, hasta un año |
* Solo se aplica a los discos con la expansión a petición habilitada.
** Solo se aplica a los discos con rendimiento extra habilitado (versión preliminar).
El número de discos que elija depende del tamaño de disco elegido. Puede usar un único disco P50 o varios discos P10 para cubrir los requisitos de la aplicación. Tenga en cuenta las consideraciones que se indican aquí a la hora de elegir.
Límites de escala (IOPS y rendimiento)
Los límites de IOPS y rendimiento del tamaño de cada disco Premium son diferentes e independientes de los límites de escala de la máquina virtual. Asegúrese de que la IOPS y el rendimiento totales de los discos están dentro de los límites de escala del tamaño de máquina virtual elegido.
Por ejemplo, si un requisito de la aplicación es un rendimiento máximo de 250 MB/s y usa una máquina virtual DS4 con un solo disco P30, la máquina virtual DS4 puede proporcionar un máximo rendimiento de 256 MB/s. Sin embargo, un solo disco P30 tiene un límite de rendimiento de 200 MB/s. Por lo tanto, la aplicación está restringida a 200 MB/s debido al límite de disco. Para superar este límite, aprovisione más de un disco de datos para la máquina virtual o cambie el tamaño de los discos a P40 o P50.
Nota:
Las lecturas atendidas por la caché no se incluyen en la IOPS y el rendimiento del disco, por lo que no están sujetas a los límites del disco. La caché tiene su límite de IOPS y rendimiento independiente de la máquina virtual.
Por ejemplo, inicialmente sus lecturas y escrituras son de 60 MB/s y 40 MB/s, respectivamente. Con el tiempo, la memoria caché se prepara y atiende cada vez más y más lecturas de la memoria caché. Entonces, puede obtener un mayor rendimiento de escritura desde el disco.
Número de discos
Determine el número de discos que necesita evaluando los requisitos de la aplicación. Cada tamaño de máquina virtual también tiene un límite en el número de discos que puede conectar a la máquina virtual. Normalmente, esta cantidad es el doble del número de núcleos. Asegúrese de que el tamaño de la máquina virtual que elija puede admitir el número de discos necesario.
Recuerde que los discos de Premium Storage tienen capacidades de rendimiento superiores en comparación con los discos de Standard Storage. Si va a migrar la aplicación desde una máquina virtual IaaS de Azure mediante Standard Storage a Premium Storage, es probable que necesite menos discos premium para conseguir un rendimiento igual o superior para la aplicación.
Almacenamiento en caché de disco
Las máquinas virtuales a gran escala que usan Premium Storage tienen una tecnología de almacenamiento en caché de varios niveles denominada BlobCache. BlobCache usa una combinación de la RAM del host y del SSD local para almacenar en caché. Esta memoria caché está disponible para los discos de Premium Storage persistentes y los discos locales de la máquina virtual. De forma predeterminada, esta configuración de la caché se establece en ReadWrite para los discos del sistema operativo y en ReadOnly para los discos de datos hospedados en Premium Storage. Con el almacenamiento en caché de disco habilitada en los discos de Premium Storage, la máquinas virtuales a gran escala pueden lograr niveles de rendimiento extremadamente altos que superan el rendimiento del disco subyacente.
Advertencia
El almacenamiento en caché de disco no se admite para discos de 4 TiB y más grandes. Si hay varios discos conectados a la máquina virtual, todos los discos de menos de 4 TiB admiten el almacenamiento en caché.
Al cambiar la configuración de caché de un disco de Azure, se desasocia y se vuelve a asociar el disco de destino. Si se trata del disco del sistema operativo, se reinicia la máquina virtual. Detenga todas las aplicaciones y servicios que podrían verse afectados por esta interrupción antes de cambiar la configuración de caché del disco. El incumplimiento de estas recomendaciones podría provocar datos dañados.
Para obtener más información sobre el funcionamiento de BlobCache, consulte la publicación de blog Dentro de Azure Premium Storage.
Es importante habilitar el almacenamiento en caché en el conjunto de discos correcto. Si debe habilitar el almacenamiento en caché de disco en un disco de premium o no depende del patrón de la carga de trabajo que maneja el disco. La tabla siguiente muestra el valor predeterminado de las opciones de caché para discos del sistema operativo y datos.
Tipo de disco | Configuración de la memoria caché predeterminada |
---|---|
Disco del sistema operativo | ReadWrite |
Disco de datos | ReadOnly |
Se recomienda la siguiente configuración de caché de disco para los discos de datos.
Configuración del almacenamiento en caché de disco | Recomendación sobre cuándo debe usarse esta configuración |
---|---|
Ninguno | Configure la caché de host en None para los discos de solo escritura y con escritura intensiva. |
ReadOnly | Configure la caché de host en ReadOnly para los discos de solo lectura y de lectura y escritura. |
ReadWrite | Configure la caché de host en ReadWrite solo si la aplicación maneja correctamente la escritura de datos en caché a discos persistentes cuando es necesario. |
ReadOnly
Mediante la configuración del almacenamiento en caché ReadOnly en discos de datos de Premium Storage, puede lograr una baja latencia de lectura y obtener una IOPS de lectura y un rendimiento de la aplicación muy altos por dos motivos:
- Las lecturas hechas desde la memoria caché, que se encuentra en la memoria de la máquina virtual y el SSD local, son más rápidas que las lecturas desde el disco de datos, que se encuentra en Azure Blob Storage.
- Premium Storage no cuenta las lecturas que se atienden desde la caché hacia la IOPS y el rendimiento del disco. Por este motivo, la aplicación puede lograr una IOPS y un rendimiento totales mayores.
ReadWrite
De forma predeterminada, los discos del sistema operativo tienen habilitado el almacenamiento en caché ReadWrite. Recientemente se ha agregado compatibilidad con el almacenamiento en caché ReadWrite en los discos de datos. Si usa el almacenamiento en caché ReadWrite, debe tener una manera adecuada de escribir los datos de la memoria caché en discos persistentes. Por ejemplo, SQL Server administra por sí mismo la escritura de los datos en caché en los discos de almacenamiento persistentes. El uso de la caché ReadWrite con una aplicación que no administre la persistencia de los datos necesarios puede provocar la pérdida de los datos, si se bloquea la máquina virtual.
Ninguno
Actualmente, None solo se admite en discos de datos. No se admite en los discos del sistema operativo. Si establece None en un disco del sistema operativo, se invalidará esta configuración internamente y se establecerá en ReadOnly.
Por ejemplo, puede aplicar estas directrices a una instancia de SQL Server que se ejecuta en Premium Storage siguiendo estos pasos:
- Configure la caché ReadOnly en discos de Premium Storage que hospedan archivos de datos.
- Las rápidas lecturas de la caché reducen el tiempo de consulta de SQL Server porque las páginas de datos se recuperan más rápido de la memoria caché que directamente desde los discos de datos.
- Atender las lecturas de la caché implica que hay más rendimiento disponible de los discos de datos premium. SQL Server puede usar este rendimiento adicional para recuperar más páginas de datos y otras operaciones, como copia de seguridad/restauración, cargas por lotes y volver a generar un índice.
- Configure la caché None en los discos de Premium Storage que hospedan los archivos de registro.
- Los archivos de registro tienen principalmente operaciones de escritura intensiva, por lo que no se benefician de la caché ReadOnly.
Optimización del rendimiento en máquinas virtuales Linux
En el caso de todas las SSD Premium o discos Ultra, es posible que pueda deshabilitar barreras para sistemas de archivos en el disco para mejorar el rendimiento cuando se sabe que no hay cachés que puedan perder datos. Si el almacenamiento en caché de Azure está establecido en ReadOnly o en None, puede deshabilitar las barreras. Pero si el almacenamiento en caché se establece en ReadWrite, las barreras deben permanecer habilitadas para garantizar la durabilidad de la escritura. Normalmente, las barreras están habilitadas de forma predeterminada, pero puede deshabilitarlas usando uno de los siguientes métodos, en función del tipo de sistema de archivos:
- reiserFS: use la opción de montaje barrier=none para deshabilitar las barreras. Para habilitar las barreras de forma explícita, use barrier=flush.
- ext3/ext4: use la opción de montaje barrier=0 para deshabilitar las barreras. Para habilitar las barreras de forma explícita, use barrier=1.
- XFS: use la opción de montaje nobarrier para deshabilitar las barreras. Para habilitar las barreras de forma explícita, use barrier. A partir de la versión 4.10 del kernel de Linux de línea principal, el diseño del sistema de archivos XFS siempre garantiza la durabilidad. Deshabilitar barreras no tiene ningún efecto y la opción nobarrier está en desuso. Sin embargo, es posible que algunas distribuciones de Linux hayan devuelto los cambios a una versión de distribución con una versión de kernel anterior. Compruebe con el proveedor de distribución el estado de la distribución y la versión que está ejecutando.
Seccionamiento del disco
Cuando una máquina virtual a gran escala esté conectada a varios discos persistente almacenamiento premium, los discos se pueden seccionar conjuntamente para agregar sus IOPS, ancho de banda y capacidad de almacenamiento.
En Windows, puede usar espacios de almacenamiento para seccionar discos conjuntamente. Debe configurar una columna para cada disco de un grupo. De lo contrario, el rendimiento general del volumen seccionado puede ser inferior al esperado debido a una distribución desigual del tráfico entre los discos.
Con la UI del Administrador del servidor, puede establecer el número total de columnas hasta en 8
para un volumen seccionado. Al conectar más de ocho discos, use PowerShell para crear el volumen. Mediante PowerShell, puede establecer un número de columnas igual al número de discos. Por ejemplo, si hay 16 discos en un único conjunto de franjas, especifique 16
columnas en el parámetro NumberOfColumns
del cmdlet New-VirtualDisk
de PowerShell.
En Linux, use la utilidad MDADM para seccionar discos conjuntamente. Para ver los pasos sobre cómo seccionar discos en Linux, consulte Configuración del software RAID en Linux.
Stripe size (Tamaño de las franjas)
Una configuración importante en el seccionamiento del disco es el tamaño de franja. El tamaño de franja o tamaño de bloque es el fragmento de datos más pequeño que puede manejar una aplicación en un volumen seccionado. El tamaño de franja que configurar depende del tipo de aplicación y su patrón de solicitudes. Si elije un tamaño de franja incorrecto, podría provocar la desalineación de E/S, lo que conduce a una disminución del rendimiento de la aplicación.
Por ejemplo, si una solicitud de E/S generada por la aplicación es mayor que el tamaño de franja del disco, el sistema de almacenamiento escribe a través de límites de la unidad de franja en más de un disco. Cuando llega el momento de acceder a esos datos, tiene que buscar en las unidades con más de una franja para completar la solicitud. El efecto acumulativo de este comportamiento puede provocar una degradación del rendimiento considerable. Por otro lado, si el tamaño de la solicitud de E/S es menor que el tamaño de franja, y si es aleatoria por naturaleza, las solicitudes de E/S pueden acumularse en el mismo disco, causar un cuello de botella y, en última instancia, degradar el rendimiento de E/S.
Según el tipo de carga de trabajo que se ejecute la aplicación, elija un tamaño de franja adecuado. Para solicitudes de E/S pequeñas aleatorias, use un tamaño de franja más pequeño. Para las solicitudes de E/S secuenciales grandes, use un tamaño de franja mayor. Descubra las recomendaciones de tamaño de franja para la aplicación que va a ejecutar en Premium Storage. Para SQL Server, configure un tamaño de franja de 64 KB para las cargas de trabajo OLTP y de 256 KB para las cargas de trabajo de almacenamiento de datos. Para obtener más información, consulte Procedimientos recomendados de rendimiento para SQL Server en máquinas virtuales de Azure.
Nota:
Puede seccionar conjuntamente un máximo de 32 discos de almacenamiento premium en una serie de máquinas virtuales DS y 64 discos de almacenamiento premium en una serie de máquinas virtuales GS.
Subprocesamiento múltiple
Azure diseñó la plataforma Premium Storage para ser enormemente paralela. Por este motivo, una aplicación multiproceso logra un rendimiento mayor que una aplicación de un solo proceso. Una aplicación multiproceso divide sus tareas en varios subprocesos y aumenta la eficacia de su ejecución mediante el uso de los recursos de la máquina virtual y el disco al máximo.
Por ejemplo, si la aplicación se ejecuta en una máquina virtual de un solo núcleo que usa dos subprocesos, la CPU puede cambiar entre los dos subprocesos para lograr la eficiencia. Mientras un subproceso está esperando que se complete la E/S del disco, la CPU puede cambiar a otro subproceso. De esta manera, dos subprocesos pueden lograr más que un único subproceso. Si la máquina virtual tiene más de un núcleo, reduce aún más el tiempo de ejecución, ya que cada núcleo puede ejecutar tareas en paralelo.
Es posible que no pueda cambiar la forma en que una aplicación comercial implementa subprocesos únicos o multithreading. Por ejemplo, SQL Server es capaz de manejar varios núcleos y varias CPU. Sin embargo, SQL Server determina en qué condiciones usa uno o varios subprocesos para procesar una consulta. Puede ejecutar consultas y generar los índices mediante el multithreading. Para una consulta que implica combinar tablas grandes y ordenar los datos antes de devolverlos al usuario, SQL Server probablemente usará varios subprocesos. Un usuario no puede controlar si SQL Server ejecuta una consulta con un único subproceso o con varios subprocesos.
Hay opciones de configuración que puede modificar para tener en cuenta el multithreading o el procesamiento en paralelo de una aplicación. Por ejemplo, para SQL Server, es la configuración max degree of parallelism
. Esta configuración, denominada MAXDOP, permite configurar el número máximo de procesadores que puede usar SQL Server cuando realiza el procesamiento en paralelo. Puede configurar MAXDOP para consultas individuales u operaciones de índice. Esta capacidad es beneficiosa cuando desea equilibrar los recursos del sistema para una aplicación crítica para el rendimiento.
Por ejemplo, supongamos que su aplicación que usa SQL Server ejecuta una consulta de gran tamaño y una operación de índice al mismo tiempo. Supongamos que desea que la operación de índice sea más eficaz en comparación con la consulta de gran tamaño. En tal caso, puede establecer el valor de MAXDOP de la operación de índice para que sea mayor que el valor de MAXDOP para la consulta. De este modo, SQL Server tiene más procesadores de los que puede usar para la operación de índice en comparación con el número de procesadores que puede dedicar a la consulta de gran tamaño. Recuerde que no controla el número de subprocesos que usa SQL Server para cada operación. Puede controlar el número máximo de procesadores que se dedicó a multithreading.
Obtenga más información sobre los grados de paralelismo en SQL Server. Descubra cómo esta configuración influye en el multithreading en la aplicación y sus configuraciones para optimizar el rendimiento.
Profundidad de la cola
La profundidad de la cola, la longitud de la cola o el tamaño de la cola es el número de solicitudes de E/S pendientes en el sistema. El valor de la profundidad de la cola determina cuántas operaciones de E/S, que procesan los discos de almacenamiento, puede alinear la aplicación. Afecta a los tres indicadores de rendimiento de las aplicaciones descritos en este artículo: IOPS, rendimiento y latencia.
La profundidad de la cola y el multithreading están estrechamente relacionados. El valor de la profundidad de la cola indica la cantidad de multithreading que puede lograr la aplicación. Si la profundidad de la cola es grande, la aplicación puede ejecutar más operaciones simultáneamente, es decir, más multithreading. Si la profundidad de la cola es pequeña, incluso si la aplicación es multithreading, no tendrá suficientes solicitudes alineadas para la ejecución simultánea.
Normalmente, las aplicaciones comerciales no le permiten cambiar la profundidad de la cola, porque si se establece incorrectamente, hará más daño que beneficio. Las aplicaciones establecen el valor correcto de profundidad de la cola para obtener un rendimiento óptimo. Es importante entender este concepto, para que pueda solucionar problemas de rendimiento con la aplicación. También puede observar los efectos de profundidad de la cola mediante la ejecución de herramientas de pruebas comparativas del sistema.
Algunas aplicaciones proporcionan opciones para influir en la profundidad de la cola. Por ejemplo, la configuración MAXDOP de SQL Server se explica en la sección anterior. MAXDOP es una forma de influir en la profundidad de la cola y el multi-threading, aunque no cambia directamente el valor de Profundidad de la cola de SQL Server.
Profundidad de cola alta
Una profundidad de la cola alta alinea más operaciones en el disco. El disco conoce la siguiente solicitud de su cola de antemano. Por lo tanto, el disco puede programar las operaciones de antemano y procesarlas en una secuencia óptima. Como la aplicación envía más solicitudes al disco, este puede procesar más E/S paralelas. En última instancia, la aplicación puede lograr una mayor IOPS. Como la aplicación está procesando más solicitudes, también aumenta el rendimiento total de la aplicación.
Normalmente, una aplicación puede lograr un rendimiento máximo con 8 a +16 E/S pendientes por disco conectado. Si la profundidad de la cola es uno, la aplicación no inserta suficientes E/S en el sistema y procesa una cantidad menor en un período determinado. En otras palabras, menor rendimiento.
Por ejemplo, en SQL Server, si se establece el valor de MAXDOP en una consulta en 4
, se informa a SQL Server de que puede usar un máximo de cuatro núcleos para ejecutar la consulta. SQL Server determina el mejor valor de profundidad de la cola y el número de núcleos para la ejecución de la consulta.
Profundidad de la cola óptima
Un valor de profundidad de la cola muy alto también tiene sus inconvenientes. Si el valor de profundidad de la cola es demasiado alto, la aplicación intenta manejar una IOPS muy alta. A menos que la aplicación tenga discos persistentes con suficientes IOPS aprovisionadas, un valor de profundidad de la cola muy alto puede afectar negativamente a las latencias de la aplicación. La siguiente fórmula muestra la relación entre la E/S por segundo, la latencia y la profundidad de la cola.
No debe configurar la profundidad de la cola en cualquier valor alto, sino en un valor óptimo, que puede ofrecer suficientes IOPS para la aplicación sin afectar a las latencias. Por ejemplo, si la latencia de la aplicación debe ser 1 milisegundo, la profundidad de la cola necesaria para lograr 5000 IOPS es QD = 5000 x 0,001 = 5.
Profundidad de la cola para un volumen seccionado
Para un volumen seccionado, mantenga una profundidad de la cola lo suficientemente alta para que cada disco tenga una profundidad de la cola máxima individual. Por ejemplo, imagine una aplicación que inserta una profundidad de cola de 2
y hay cuatro discos en la franja. Las dos solicitudes de E/S van a dos discos y los dos discos restantes están inactivos. Por lo tanto, configure la profundidad de la cola de modo que todos los discos puedan estar ocupados. La siguiente fórmula muestra cómo determinar la profundidad de la cola de volúmenes seccionados.
Limitaciones
Premium Storage aprovisiona un número especificado de IOPS y rendimiento de acuerdo con los tamaños de la máquina virtual y de disco que elija. Cada vez que la aplicación intenta que la IOPS o el rendimiento estén por encima de los límites que puede administrar la máquina virtual o el disco, Premium Storage lo limita. El resultado es una reducción del rendimiento en la aplicación, lo que puede implicar una mayor latencia, un menor rendimiento o una IOPS más baja.
Si Premium Storage no lo limita, la aplicación podría fallar completamente al exceder lo que sus recursos son capaces de conseguir. Para evitar problemas de rendimiento debido a la limitación, aprovisione siempre suficientes recursos para la aplicación. Tenga en cuenta lo que se describe en las secciones anteriores sobre los tamaños de la máquina virtual y del disco. Las pruebas comparativas son la mejor forma de averiguar qué recursos necesita para hospedar la aplicación.
Pasos siguientes
Si quiere hacer pruebas comparativas de su disco, consulte los artículos siguientes:
- Para Linux: Ejecución de un banco de pruebas de la aplicación en Azure Disk Storage.
- Para Windows: pruebas comparativas de un disco
Más información sobre los tipos de disco disponibles:
- Para Linux: Selección de un tipo de disco
- Para Windows: Selección de un tipo de disco
Para los usuarios de SQL Server, lea los artículos sobre los procedimientos recomendados de rendimiento para SQL Server: