Resultados do parâmetro de comparação

5 minutos

Agora, examinaremos os resultados do parâmetro de comparação para verificar as dicas de desempenho que discutimos na unidade anterior. Especificamente, vamos nos concentrar no uso do conjunto de parâmetros de comparação SPEC SFS para gerar vários threads que simulam cargas de trabalho de EDA do tipo produção. Também mostraremos os resultados do FIO para examinar algumas práticas de desempenho.

Visão geral das duas ferramentas de parâmetro de comparação

O pacote SPEC SFS é um parâmetro de comparação do setor padrão para o EDA. Uma carga de trabalho típica de EDA consiste em fases funcionais e físicas. A fase funcional orienta principalmente as operações de metadados e de E/S aleatórias e de sistema de arquivos. A fase física orienta as leituras e as gravações sequenciais de blocos grandes.

O FIO é uma ferramenta de E/S que pode gerar cargas de leitura/gravação aleatórias ou sequenciais consistentes que sirvam como parâmetro de comparação de IOPS e de taxa de transferência de um destino de armazenamento.

Tipos de volume no Azure NetApp Files

O Azure NetApp Files fornece dois tipos de volumes que podem ser provisionados para armazenamento de dados na nuvem: volumes regulares e volumes grandes. A tabela a seguir destaca algumas das principais diferenças entre os dois tipos de volume. Use esta tabela como orientação ao escolher o tipo de volume certo para sua carga de trabalho.

Limite	Volume regular	Volume grande
Capacidade mínima	100 GiB	50 TiB
Capacidade máxima	100 TiB	500 TiB
Nível mínimo de serviço com suporte	Standard	Standard
Taxa de transferência máxima observada	4\.500 MiB/s	10.240 MiB/s
IOPS de leitura máxima observada	~200,000	~700,000
IOPS de gravação máxima observada	~135,000	~474,000

Resultados de parâmetro de comparação da ferramenta SPEC EDA para volumes regulares

Os grafos desta seção demonstram as curvas de E/S e latência. Eles examinam algumas combinações das seguintes práticas de desempenho:

nocto,actimeo=600
sysctl tuned
nconnect=16

Quando as três práticas anteriores são aplicadas, as operações de E/S por segundo aumentam e ainda mantêm uma latência baixa (menos de 1 milissegundo).

Diagrama que mostra os resultados do SPEC EDA, em que o aumento de E/S ainda mantém uma latência baixa quando as três práticas são aplicadas.

O grafo a seguir demonstra que o NFSv3 tem um desempenho melhor que o NFSv4.1 para esse tipo de carga de trabalho.

Diagrama que mostra os resultados do SPEC EDA, em que o NFS versão 3 tem um desempenho melhor do que o NFS versão 4.1.

O grafo a seguir demonstra que o rsize=wsize=262144(256 K) tem um desempenho melhor do que outras configurações.

Diagrama que mostra os resultados do SPEC EDA para comparar os valores do rsize e do wsize.

Resultados do parâmetro de comparação da ferramenta SPEC EDA para volumes grandes

O teste de limite de desempenho foi realizado em um único volume grande usando o parâmetro de comparação do SPEC SFS com a seguinte configuração:

Tipo de configuração	Configuração
Sistema operacional	RHEL 9.3 / RHEL 8.7
Tipo de instância	D16s_v5
Contagem de instâncias	10
Opções de montagem	nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8

Os testes compararam os recursos de desempenho de um volume grande usando o parâmetro de comparação SPEC SFS em comparação com um volume regular no Azure NetApp Files.

Cenário	Taxa de E/S em 2ms	MiB/s a 2ms
Um volume regular	39.601	692
Um volume grande	652.260	10.030

Diagrama comparando latência e taxa de transferência para um volume grande.

Resultados de comparação da ferramenta FIO para volumes regulares

Os comandos do FIO a seguir comparam a IOPS e a taxa de transferência, 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

Os dois grafos a seguir demonstram que, quando nocto,actimeo=600, nconnect=16 e sysctl são ajustados, o Azure NetApp Files pode atingir uma IOPS e uma taxa de transferência mais altas.

Diagrama mostrando os resultados do FIO de uma IOPS mais alta.

Diagrama mostrando os resultados do FIO de uma taxa de transferência mais alta.

Resultados de comparação da ferramenta FIO para volumes grandes

Esta seção descreve os limites de desempenho de um único volume grande usando o parâmetro de comparação FIO. Os testes foram executados com a seguinte configuração:

Componente	Configuração
Tamanho da VM do Azure	E32s_v5
Limite de largura de banda de saída da VM do Azure	2.000 MiB/s (2 GiB/s)
Sistema operacional	RHEL 8.4
Tamanho de volume grande	101 TiB Ultra (taxa de transferência de 10.240 MiB/s)
Opções de montagem	hard,rsize=65536,wsize=65536,vers=3 Observação: o uso de ambos 262144 e 65536 teve resultados de desempenho semelhantes.

Cargas de trabalho sequenciais de 256 KiB (MiB/s)

O gráfico representa uma carga de trabalho sequencial de 256 KiB e um conjunto de trabalho de 1 TiB. Ele mostra que um único volume do Azure NetApp Files pode lidar com aproximadamente 8.518 MiB/s de gravações sequenciais puras e 9.970 MiB/s de leituras sequenciais puras.

Carga de trabalho aleatória de 8 KiB (IOPS)

O gráfico representa uma carga de trabalho aleatória de 8 KiB e um conjunto de trabalho de 1 TiB. O gráfico mostra que um grande volume do Azure NetApp Files pode manipular aproximadamente 474.000 gravações aleatórias puras e 709.000 leituras aleatórias puras.