Resultados de punto de referencia
Ahora, se examinan los resultados de los puntos de referencia para comprobar las sugerencias de rendimiento analizadas en la unidad anterior. Concretamente, nos centraremos en el uso del conjunto de puntos de referencia SFS de SPEC para generar varios subprocesos que simulen cargas de trabajo de producción de EDA. También se mostrarán los resultados de FIO para examinar algunos procedimientos de rendimiento.
Información general de las dos herramientas de punto de referencia
El conjunto SFS de SPEC es un punto de referencia estándar del sector para EDA. Una carga de trabajo de EDA típica consta de fases funcionales y físicas. La fase funcional impulsa principalmente operaciones aleatorias de metadatos de E/S y del sistema de archivos. La fase física impulsa lecturas y escrituras secuenciales de bloques grandes.
FIO es una herramienta de E/S que puede generar cargas de lectura y escritura secuenciales o aleatorias coherentes para definir puntos de referencia de IOPS y rendimiento de un destino de almacenamiento.
Tipos de volumen en Azure NetApp Files
Azure NetApp Files proporciona dos tipos de volúmenes que se pueden aprovisionar para el almacenamiento de datos en la nube: volúmenes regulares y grandes volúmenes. En la tabla siguiente se resaltan algunas de las principales diferencias entre los dos tipos de volumen. Use esta tabla como guía al elegir el tipo de volumen adecuado para la carga de trabajo.
| Límite | Volumen normal | Gran volumen |
|---|---|---|
| Capacidad mínima | 100 GiB | 50 TiB |
| Capacidad máxima | 100 TiB | 500 TiB |
| Nivel de servicio mínimo admitido | Estándar | Estándar |
| Rendimiento máximo observado | 4500 MiB/s | 10.240 MiB/s |
| IOPS de lectura máxima observada | ~200.000 | ~700.000 |
| IOPS de escritura máxima observada | ~135.000 | ~474.000 |
Resultados de pruebas comparativas de la herramienta SPEC EDA para volúmenes regulares
En los gráficos de esta sección se muestran las curvas de E/S y latencia. Examinan algunas combinaciones de los procedimientos de rendimiento siguientes:
nocto,actimeo=600sysctl tunednconnect=16
Cuando se aplican los tres procedimientos anteriores, las operaciones de E/S por segundo aumentan y mantienen una latencia baja (menos de 1 milisegundo).
En el gráfico siguiente se muestra que NFSv3 funciona mejor que NFSv4.1 para este tipo de carga de trabajo.
En el gráfico siguiente se muestra que rsize=wsize=262144(256 K) funciona mucho mejor que otros valores.
Resultados de pruebas comparativas de la herramienta SPEC EDA para grandes volúmenes
Las pruebas de umbral de rendimiento se realizaron en un único volumen grande mediante el banco de pruebas SFS de SPEC con la siguiente configuración:
| Tipo de configuración | Configuración |
|---|---|
| Sistema operativo | RHEL 9.3 / RHEL 8.7 |
| Tipo de instancia | D16s_v5 |
| Recuento de instancias | 10 |
| Opciones de montaje | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
Las pruebas comparan las funcionalidades de rendimiento de un gran volumen mediante el banco de pruebas SFS de SPEC en comparación con un volumen normal en Azure NetApp Files.
| Escenario | Velocidad de E/S a 2 ms | MiB/s a 2 ms |
|---|---|---|
| Un volumen normal | 39 601 | 692 |
| Un gran volumen | 652,260 | 10,030 |
Resultados de pruebas comparativas de la herramienta FIO para volúmenes regulares
Los comandos de FIO siguientes crean puntos de referencia de IOPS y rendimiento, respectivamente.
// FIO commands to benchmark IOPS:
// 8K Random Reads
fio --name=8krandomreads --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 8K Random Writes
fio --name=8krandomwrites --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// FIO commands to benchmark throughput:
// 64K Sequential Reads
fio --name=64kseqreads --rw=read --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 64K Sequential Writes
fio --name=64kseqwrites --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
En los dos gráficos siguientes se muestra que, cuando se ajustan nocto,actimeo=600, nconnect=16 y sysctl, Azure NetApp Files puede conseguir IOPS y un rendimiento superiores.
Resultados de pruebas comparativas de la herramienta FIO para grandes volúmenes
En esta sección se describen los umbrales de rendimiento de un único volumen grande mediante el banco de pruebas FIO. Las pruebas se ejecutaron con la siguiente configuración:
| Componente | Configuración |
|---|---|
| Tamaño de la máquina virtual de Azure | E32s_v5 |
| Límite de ancho de banda de salida de máquinas virtuales de Azure | 2000MiB/s (2GiB/s) |
| Sistema operativo | RHEL 8.4 |
| Tamaño de volumen grande | 101 TiB Ultra (rendimiento de 10 240 MiB/s) |
| Opciones de montaje | hard,rsize=65536,wsize=65536,vers=3 NOTA: Uso de 262144 y 65536 tenían resultados de rendimiento similares. |
256-KiB cargas de trabajo secuenciales (MiB/s)
El gráfico representa una carga de trabajo secuencial de 256 KiB y un conjunto de trabajo de 1 TiB. Muestra que un único volumen grande de Azure NetApp Files puede controlar entre aproximadamente 8 518 escrituras secuenciales puras de MiB/s y 9 970 MiB/s lecturas secuenciales puras.
Carga de trabajo aleatoria de 8 KiB (IOPS)
El gráfico representa una carga de trabajo aleatoria de 8 KiB y un conjunto de trabajo de 1 TiB. El gráfico muestra que un volumen grande de Azure NetApp Files puede controlar entre aproximadamente 474 000 escrituras aleatorias puras y aproximadamente 709 000 lecturas aleatorias puras.
