Armazenamento Premium do Azure: criar aplicativos para obter alto desempenho
Aplica-se a: ✔️ VMs do Linux ✔️ VMs do Windows ✔️ Conjuntos de dimensionamento flexíveis ✔️ Conjuntos de dimensionamento uniformes
Este artigo fornece diretrizes para a criação de aplicativos de alto desempenho usando o Armazenamento Premium do Azure. Você pode usar as instruções fornecidas neste documento combinadas com as práticas recomendadas de desempenho aplicáveis às tecnologias usadas pelo aplicativo. Para ilustrar as diretrizes, usamos o SQL Server em execução no Armazenamento Premium como exemplo em todo este documento.
Embora, neste artigo, tenhamos abordado cenários da camada de armazenamento, você precisará otimizar a camada de aplicativo. Por exemplo, se você estiver hospedando um farm do SharePoint no Armazenamento Premium, use os exemplos do SQL Server deste artigo para otimizar o servidor de banco de dados. Otimize também o servidor Web e o servidor de aplicativos do farm do SharePoint para obter o melhor desempenho possível.
Este artigo ajuda a responder às seguintes perguntas comuns sobre como otimizar o desempenho de aplicativos no Armazenamento Premium:
- Como você pode avaliar o desempenho do aplicativo?
- Por que você não está vendo o alto desempenho esperado?
- Quais fatores influenciam o desempenho do aplicativo no Armazenamento Premium?
- Como esses fatores influenciam o desempenho do aplicativo no Armazenamento Premium?
- Como você pode otimizar a IOPS (operações de entrada/saída por segundo), a largura de banda e a latência?
Fornecemos estas diretrizes especificamente para o Armazenamento Premium porque as cargas de trabalho em execução no Armazenamento Premium são altamente sensíveis ao desempenho. Apresentamos exemplos quando apropriado. Também é possível aplicar algumas dessas diretrizes a aplicativos em execução nas VMs da IaaS (infraestrutura como serviço) com os discos do Armazenamento Standard.
Observação
Às vezes, o que parece ser um problema de desempenho de disco é, na verdade, um gargalo de rede. Nessas situações, você deve otimizar seu desempenho de rede.
Caso pretenda avaliar o desempenho do disco, confira os seguintes artigos:
- No Linux: submeter seu aplicativo a benchmark no Armazenamento em Disco do Azure
- No Windows: Avaliar o desempenho de um disco
Se a sua VM der suporte à rede acelerada, verifique se ela está habilitada. Caso ela não esteja, habilite-a nas VMs já implantadas no Windows e no Linux.
Antes de começar, se você estiver começando a usar o Armazenamento Premium agora, leia primeiro os artigos Selecionar um tipo de disco do Azure para VMs de IaaS e Metas de escalabilidade para contas de armazenamento de blobs de páginas premium.
Indicadores de desempenho de aplicativo
Avaliamos se um aplicativo está tendo um bom desempenho ou não usando indicadores de desempenho como:
- A velocidade com que um aplicativo processa uma solicitação de usuário.
- O volume de dados que um aplicativo processa por solicitação.
- O número de solicitações que um aplicativo processa em um período específico.
- O tempo que um usuário precisa esperar para obter uma resposta após o envio de uma solicitação.
Os termos técnicos para esses indicadores de desempenho são IOPS, taxa de transferência ou largura de banda e latência.
Nesta seção, discutiremos os indicadores comuns de desempenho no contexto do Armazenamento Premium. Na seção Lista de verificação de desempenho de aplicativos para discos, você aprenderá a medir esses indicadores de desempenho para seu aplicativo. Mais adiante, em Otimizar o desempenho do aplicativo, você conhecerá os fatores que afetam esses indicadores de desempenho e as recomendações para otimizá-los.
IOPS
A IOPS é o número de solicitações que o aplicativo envia para os discos de armazenamento em um segundo. Uma operação de entrada/saída pode ser de leitura ou gravação, sequencial ou aleatória. Os aplicativos OLTP (processamento de transações online), como um site de varejo online, precisam processar muitas solicitações simultâneas de usuários instantaneamente. As solicitações de usuário são transações de banco de dados com grande volume de inserções e atualizações, que o aplicativo precisa processar rapidamente. Por esse motivo, os aplicativos OLTP exigem uma IOPS bastante alta.
Esses aplicativos processam milhões de solicitações de E/S aleatórias e pequenas. Se você tiver um aplicativo desse tipo, será preciso projetar a infraestrutura do aplicativo para otimização de IOPS. Para obter mais informações sobre todos os fatores a serem considerados para obter uma IOPS alta, confira Otimizar o desempenho do aplicativo.
Quando você anexa um disco do Armazenamento Premium à sua VM de alta escala, o Azure provisiona um número garantido de IOPS de acordo com a especificação do disco. Por exemplo, um disco P50 provisiona 7.500 IOPS. Cada tamanho de VM de alta escala também tem um limite específico de IOPS que ele pode manter. Por exemplo, uma VM GS5 Standard tem um limite de 80 mil IOPS.
Produtividade
A taxa de transferência ou largura de banda é o volume de dados que o aplicativo envia aos discos de armazenamento em um intervalo especificado. Se o aplicativo estiver executando operações de entrada/saída com tamanhos grandes de unidade de E/S, ele exigirá uma alta taxa de transferência. Os aplicativos de data warehouse tendem a emitir operações com uso intensivo de verificação que acessam grandes partes de dados por vez e geralmente executam operações em massa. Em outras palavras, esses aplicativos exigem uma taxa de transferência mais alta. Caso você tenha um aplicativo desse tipo, será preciso projetar sua infraestrutura para otimização da taxa de transferência. Na próxima seção, abordaremos os fatores que você precisa ajustar para conseguir essa otimização.
Quando você anexa um disco do armazenamento Premium a uma VM de alta escala, o Azure provisiona a taxa de transferência de acordo com a especificação desse disco. Por exemplo, um disco P50 provisiona taxas de transferência de disco de 250 MB/s. Cada tamanho de VM de alta escala também tem um limite específico de taxa de transferência que ele pode manter. Por exemplo, a VM GS5 Standard tem uma taxa de transferência máxima de 2.000 MB/s.
Há uma relação entre taxa de transferência e IOPS, como mostrado na fórmula a seguir.
É importante determinar os valores ideais de taxa de transferência e de IOPS exigidas pelo aplicativo. Quando você tenta otimizar um deles, o outro também é afetado. Para obter mais informações sobre como otimizar a IOPS e a taxa de transferência, confira Otimizar o desempenho do aplicativo.
Latência
A latência é o tempo necessário para um aplicativo receber uma solicitação individual, enviá-la aos discos de armazenamento e enviar a resposta ao cliente. Essa é uma medida crítica do desempenho de um aplicativo, além da IOPS e da taxa de transferência. A latência de um disco do Armazenamento Premium é o tempo necessário para recuperar as informações de uma solicitação e comunicá-las de volta ao aplicativo. O Armazenamento Premium fornece latências consistentemente baixas. Os discos Premium foram projetados para fornecer latências de dígito único em milissegundos para a maioria das operações de E/S. Ao habilitar o cache do host ReadOnly nos discos do Armazenamento Premium, você obtém uma latência de leitura muito mais baixa. Para obter mais informações sobre o cache de disco, confira Cache de disco.
Quando você otimiza seu aplicativo para obter uma IOPS e uma taxa de transferência mais altas, a latência do aplicativo também é afetada. Após ajustar o desempenho do aplicativo, sempre avalie a latência dele para evitar um comportamento inesperado de alta latência.
As operações do painel de controle a seguir nos discos gerenciados podem envolver a movimentação do disco de um local de armazenamento para outro. Essa movimentação é orquestrada por meio da cópia em segundo plano dos dados, o que pode levar várias horas para ser concluído. Normalmente, esse tempo é inferior a 24 horas, dependendo do volume de dados nos discos. Durante esse tempo, seu aplicativo pode apresentar uma latência de leitura maior do que o normal, pois algumas leituras podem ser redirecionadas para a localização original e demoram mais tempo para serem concluídas.
Não há nenhum efeito na latência de gravação durante esse período. No caso dos Discos SSD Premium v2 e Ultra, se o disco tiver um tamanho de setor 4K, a latência de leitura será maior. Se o disco tiver um tamanho de setor 512e, ele terá uma latência de leitura/gravação mais alta.
As operações do painel de controle são usadas para:
- Atualize o tipo de armazenamento.
- Desanexe e anexe um disco de uma VM para outra.
- Crie um disco gerenciado com base em um VHD.
- Crie um disco gerenciado com base em um instantâneo.
- Converta uma VM de discos não gerenciados em discos gerenciados.
Lista de verificação de desempenho de aplicativos para discos
A primeira etapa na criação de aplicativos de alto desempenho executados no Armazenamento Premium é entender os requisitos de desempenho do aplicativo. Depois de entender os requisitos de desempenho, você pode otimizar o aplicativo para obter o desempenho ideal.
Na seção anterior, explicamos os indicadores comuns de desempenho: IOPS, taxa de transferência e latência. Você deve identificar quais desses indicadores de desempenho são essenciais para o aplicativo proporcionar a experiência desejada ao usuário. Por exemplo, a IOPS alta é mais importante para aplicativos OLTP que processam milhões de transações em um segundo. Uma alta taxa de transferência é crítica para aplicativos de data warehouse que processam grandes volumes de dados em um segundo. Uma latência extremamente baixa é essencial para aplicativos em tempo real, como sites de streaming de vídeo ao vivo.
Em seguida, avalie os requisitos de desempenho máximo do aplicativo durante todo o seu ciclo de vida. Use a lista de verificação de exemplo a seguir como um ponto de partida. Registre os requisitos de desempenho máximo durante os períodos de carga de trabalho normais, de pico e fora do horário comercial. Ao identificar os requisitos de todos os níveis de cargas de trabalho, você poderá determinar o requisito de desempenho geral do aplicativo.
Por exemplo, a carga de trabalho normal de um site de comércio eletrônico são as transações atendidas durante a maioria dos dias em um ano. A carga de trabalho de pico do site é composta pelas transações atendidas no fim do ano ou em datas especiais. Em geral, a carga de trabalho de pico ocorre por um tempo limitado, mas pode exigir que o aplicativo seja escalado para duas ou três vezes a operação normal. Descubra os requisitos de percentil 50, percentil 90 e percentil 99. Essas informações ajudam a filtrar as exceções nos requisitos de desempenho, e você pode concentrar seus esforços na otimização dos valores certos.
Lista de verificação dos requisitos de desempenho do aplicativo
| Requisitos de desempenho | Percentil 50 | Percentil 90 | Percentil 99 |
|---|---|---|---|
| Número total de transações por segundo | |||
| % de operações de Leitura | |||
| % de operações de Gravação | |||
| % de operações Aleatórias | |||
| % de operações Sequenciais | |||
| Tamanho da solicitação de E/S | |||
| Taxa de transferência média | |||
| Taxa de transferência máxima | |||
| Latência mínima | |||
| Latência Média | |||
| Limite máximo de CPU | |||
| CPU Média | |||
| Máximo de memória | |||
| Memória média utilizada | |||
| Profundidade da fila |
Observação
Considere a possibilidade de escalar esses números com base no futuro crescimento esperado do aplicativo. É uma boa ideia planejar o crescimento antecipadamente, pois pode ser mais difícil alterar a infraestrutura para aprimorar o desempenho mais tarde.
Se você já tiver um aplicativo e deseja migrar para o Armazenamento Premium, primeiro, crie a lista de verificação anterior para o aplicativo. Em seguida, crie um protótipo do aplicativo no Armazenamento Premium e projete o aplicativo com base nas diretrizes descritas em Otimizar desempenho do aplicativo. O próximo artigo descreve as ferramentas podem ser usadas para entender as medições de desempenho.
Contadores para avaliar requisitos de desempenho do aplicativo
A melhor maneira de avaliar os requisitos de desempenho do aplicativo é usar as ferramentas de monitoramento do PerfMon fornecidas pelo sistema operacional do servidor. Use PerfMon no Windows e iostat no Linux. Essas ferramentas capturam os contadores correspondentes a cada medida explicada na seção anterior. Você precisa capturar os valores desses contadores quando o aplicativo executa cargas de trabalho normais, de pico ou fora do horário comercial.
Os contadores do PerfMon estão disponíveis para processador, memória e cada disco lógico e físico do servidor. Quando você usa discos do Armazenamento Premium com uma VM, os contadores de disco físico são para cada disco do Armazenamento Premium e os contadores de disco lógico são para cada volume criado nos discos do Armazenamento Premium. É preciso capturar os valores dos discos que hospedam a carga de trabalho do aplicativo. Se houver um mapeamento um-para-um entre discos lógicos e físicos, você poderá consultar os contadores do disco físico. Caso contrário, consulte os contadores do disco lógico.
No Linux, o comando iostat gera um relatório de utilização de CPU e de disco. O relatório de utilização de disco fornece estatísticas por dispositivo físico ou partição. Se você tiver um servidor de banco de dados com seus dados e registrados em discos separados, colete esses dados de ambos os discos. A tabela a seguir descreve os contadores de discos, processadores e memória.
| Contador | Descrição | PerfMon | Ferramenta iostat |
|---|---|---|---|
| IOPS ou transações/s | Número de solicitações de E/S emitidas ao disco de armazenamento/s | Leituras de disco/s Gravações de disco/s |
tps r/s w/s |
| Leituras e gravações de discos | % de operações de leitura e gravação executadas no disco | % de tempo de leitura no disco % de tempo de gravação no disco |
r/s w/s |
| Produtividade | Volume de dados lidos ou gravados no disco/s | Bytes de leitura no disco/s Bytes de gravação no disco/s |
kB_read/s kB_wrtn/s |
| Latência | Tempo total para conclusão de uma solicitação de E/S de disco | Média do disco por segundo/leitura Média do disco por segundo/gravação |
await svctm |
| Tamanho de E/S | O tamanho das solicitações de E/S emitidas aos discos de armazenamento | Média de bytes do disco/leitura Média de bytes do disco/gravação |
avgrq-sz |
| Profundidade da fila | Número de solicitações de E/S pendentes aguardando leitura ou gravação no disco de armazenamento | Comprimento da fila de disco atual | avgqu-sz |
| Máximo de memória | Quantidade de memória necessária para a execução perfeita do aplicativo | % de bytes confirmados em uso | Usar o vmstat |
| Limite máximo de CPU | Quantidade de CPU necessária para a execução perfeita do aplicativo | % do Tempo do Processador | %util |
Saiba mais sobre o iostat e PerfMon.
Otimizar o desempenho do aplicativo
Os principais fatores que influenciam o desempenho de um aplicativo em execução no Armazenamento Premium são a natureza das solicitações de E/S, o tamanho da VM, o tamanho do disco, o número de discos, o cache de disco, o multithreading e a profundidade da fila. Você pode controlar alguns desses fatores com botões fornecidos pelo sistema.
A maioria dos aplicativos talvez não apresente uma opção para alterar o tamanho de E/S e a profundidade da fila diretamente. Por exemplo, se você estiver usando o SQL Server, não poderá escolher a profundidade de fila nem o tamanho de E/S. O SQL Server escolhe os valores ideais de tamanho de E/S e de profundidade da fila para obter o melhor desempenho. É importante compreender os efeitos de ambos os tipos de fatores no desempenho do aplicativo para que você possa provisionar recursos apropriados que atendam às necessidades de desempenho.
Nesta seção, consulte a lista de verificação de requisitos do aplicativo que você criou para identificar o nível de otimização necessário para o desempenho do seu aplicativo. Com base na lista de verificação, você pode determinar quais fatores desta seção você precisa ajustar.
Para ver os efeitos de cada fator no desempenho do aplicativo, execute os parâmetros de comparação na configuração do aplicativo. Para ver as etapas para executar ferramentas comuns de parâmetro de comparação em VMs do Windows e do Linux, confira os artigos sobre parâmetro de comparação no fim deste documento.
Otimizar a IOPS, a taxa de transferência e a latência em segundos
A tabela a seguir resume os fatores de desempenho e as etapas necessárias para otimizar a IOPS, a taxa de transferência e a latência. As seções posteriores a este resumo descrevem cada fator com mais detalhes.
Para obter mais informações sobre tamanhos de VM, bem como a IOPS, a taxa de transferência e a latência disponíveis para cada tipo de VM, confira Tamanhos de máquinas virtuais do Azure.
| Fatores de desempenho | IOPS | Produtividade | Latency |
|---|---|---|---|
| Cenário de exemplo | Aplicativo OLTP corporativo que exige taxa muito alta de transações por segundo. | Aplicativo de data warehouse corporativo que processa grandes volumes de dados. | Aplicativos quase em tempo real que exigem respostas instantâneas às solicitações de usuário, como jogos online. |
| Fatores de desempenho | |||
| Tamanho de E/S | Um tamanho de E/S menor gera uma IOPS mais alta. | Um tamanho de E/S maior gera uma taxa de transferência mais alta. | |
| Tamanho da VM | Use um tamanho de VM que ofereça IOPS maior que o requisito do seu aplicativo. | Use um tamanho de VM com um limite de taxa de transferência maior que o requisito do aplicativo. | Use um tamanho de VM que ofereça limites de escala maiores que o requisito do seu aplicativo. |
| Tamanho do disco | Use um tamanho de disco que ofereça IOPS maior que o requisito de seu aplicativo. | Use um tamanho de disco com um limite de taxa de transferência maior que o requisito do aplicativo. | Use um tamanho de disco que ofereça limites de escala maiores que o requisito do seu aplicativo. |
| Limites de escala de VM e de disco | O limite de IOPS do tamanho da VM escolhido deve ser maior que o total de IOPS gerado pelos discos do armazenamento anexados a ela. | O limite de taxa de transferência do tamanho da VM escolhido deve ser maior que o total de taxa de transferência gerado pelos discos do Armazenamento Premium anexados a ela. | Os limites de escala do tamanho da VM escolhido precisam ser maiores que o total de limites de escala dos discos do Armazenamento Premium anexados. |
| Cache de disco | Habilite o cache ReadOnly nos discos do Armazenamento Premium com operações com uso intensivo de leitura para obter uma IOPS de leitura mais alta. | Habilite o cache ReadOnly nos discos do Armazenamento Premium com operações com uso intensivo de leitura para obter latências de leitura muito baixas. | |
| Distribuição de discos | Use vários discos e distribua-os em conjunto para obter um limite combinado de IOPS e taxa de transferência mais altas. O limite combinado por VM deve ser maior do que os limites combinados de discos premium anexados. | ||
| Tamanho da distribuição | Tamanho menor de distribuição para padrão de E/S pequena aleatória visto em aplicativos OLTP. Por exemplo, use o tamanho de distribuição de 64 KB para um aplicativo OLTP do SQL Server. | Tamanho maior de distribuição para padrão de E/S grande sequencial visto em aplicativos de data warehouse. Por exemplo, use o tamanho de distribuição de 256 KB para um aplicativo de data warehouse do SQL Server. | |
| Multithreading | Use multithreading para enviar por push números maiores de solicitações ao Armazenamento Premium que levarão à IOPS e taxa de transferência mais altas. Por exemplo, no SQL Server, defina um valor MAXDOP alto para alocar mais CPUs ao SQL Server. | ||
| Profundidade da fila | Uma profundidade de fila maior gera uma IOPS mais alta. | Uma profundidade de fila maior gera uma taxa de transferência mais alta. | Uma profundidade de fila menor gera latências mais baixas. |
Natureza das solicitações de E/S
Uma solicitação de E/S é uma unidade da operação de entrada/saída executada pelo aplicativo. Identificar a natureza das solicitações de E/S, aleatória ou sequencial, leitura ou gravação, grande ou pequena, ajuda você a determinar os requisitos de desempenho do aplicativo. É importante entender a natureza das solicitações de E/S para tomar das decisões certas ao projetar a infraestrutura do aplicativo. As E/Ss precisam ser distribuídas de maneira uniforme para proporcionar o melhor desempenho possível.
O tamanho de E/S é um dos fatores mais importantes. O tamanho de E/S é o tamanho da solicitação de operação de entrada/saída gerada pelo aplicativo. O tamanho de E/S afeta consideravelmente o desempenho, em especial, na IOPS e na largura de banda que o aplicativo pode alcançar. A fórmula a seguir mostra a relação entre IOPS, tamanho de E/S e largura de banda/taxa de transferência.
Alguns aplicativos permitem que você altere o tamanho de E/S, ao contrário de outros. Por exemplo, o SQL Server determina por si só o tamanho ideal de E/S e não apresenta aos usuários nenhum botão para alterá-lo. Por outro lado, o Oracle oferece um parâmetro chamado DB_BLOCK_SIZE, que você pode usar para configurar o tamanho da solicitação de E/S do banco de dados.
Se estiver usando um aplicativo que não permite alterar o tamanho de E/S, use as diretrizes deste artigo para otimizar o KPI de desempenho que é mais relevante para seu aplicativo. Por exemplo:
- Um aplicativo OLTP gera milhões de solicitações de E/S pequenas e aleatórias. Para lidar com esses tipos de solicitação de E/S, você precisa projetar a infraestrutura do aplicativo para obter uma IOPS mais alta.
- Um aplicativo de data warehouse gera solicitações de E/S grandes e sequenciais. Para lidar com esses tipos de solicitação de E/S, você precisa projetar a infraestrutura do aplicativo para obter uma largura de banda ou uma taxa de transferência mais alta.
Se estiver usando um aplicativo que permita alterar o tamanho de E/S, use esta regra prática para o tamanho de E/S, além de outras diretrizes de desempenho:
- Tamanho menor de E/S para obter uma IOPS mais alta. Por exemplo, 8 KB para um aplicativo OLTP.
- Tamanho maior de E/S para obter uma largura de banda/taxa de transferência mais alta. Por exemplo, 1.024 KB para um aplicativo de data warehouse.
Veja um exemplo de como é possível calcular a IOPS e a taxa de transferência/largura de banda do seu aplicativo.
Considere um aplicativo que usa um disco P30. A IOPS e a taxa de transferência/largura de banda máxima que um disco P30 pode atingir é de 5.000 IOPS e 200 MB/s, respectivamente. Se o aplicativo exigir a IOPS máxima do disco P30 e você usar um tamanho de E/S menor, como 8 KB, a largura de banda resultante que você pode obter será de 40 MB/s. Se o aplicativo exigir a taxa de transferência/largura de banda máxima de um disco P30 e você usar um tamanho de E/S maior, como 1.024 KB, a IOPS resultante será menor, como 200 IOPS.
Ajuste o tamanho de E/S de modo que ele atenda aos requisitos de IOPS e taxa de transferência/largura de banda do aplicativo. A tabela a seguir resume os diferentes tamanhos de E/S e a IOPS e a taxa de transferência correspondentes para um disco P30.
| Requisito de aplicativo | Tamanho de E/S | IOPS | Taxa de Transferência/Largura de Banda |
|---|---|---|---|
| IOPS máximo | 8 KB | 5\.000 | 40 MB/s |
| Taxa de transferência máxima | 1.024 KB | 200 | 200 MB/s |
| Taxa de transferência máxima + IOPS alta | 64 KB | 3\.200 | 200 MB/s |
| IOPS máxima + taxa de transferência alta | 32 KB | 5\.000 | 160 MB/s |
Para obter IOPS e largura de banda mais altas do que o valor máximo de um disco individual do Armazenamento Premium, use vários discos premium distribuídos em conjunto. Por exemplo, distribua dois discos P30 para obter uma IOPS combinada de 10.000 IOPS ou uma taxa de transferência combinada de 400 MB/s. Conforme explicado na próxima seção, você precisa usar um tamanho de VM que dê suporte à IOPS de disco e à taxa de transferência combinadas.
Observação
À medida que você aumenta a IOPS ou a taxa de transferência, a outra também aumenta. Lembre-se de não atingir os limites de taxa de transferência ou de IOPS do disco ou da VM quando você aumentar uma delas.
Para ver os efeitos do tamanho de E/S no desempenho do aplicativo, execute ferramentas de parâmetros de comparação na VM e nos discos. Crie várias execuções de teste e use diferentes tamanhos de E/S para cada execução a fim de ver o efeito. Para obter mais informações, confira os artigos sobre parâmetros de comparação no final deste documento.
Tamanhos de VM de alta escala
Quando você começa a criar um aplicativo, uma das primeiras tarefas é escolher uma VM para hospedar o aplicativo. O Armazenamento Premium é fornecido com tamanhos de VM de alta escala que podem executar aplicativos que exigem potência mais alta de computação e um alto desempenho de E/S do disco local. Essas VMs fornecem processadores mais rápidos, uma taxa mais alta de memória para núcleo e uma SSD (unidade de estado sólido) para o disco local. Entre os exemplos de VMs de alta escala que dão suporte ao Armazenamento Premium estão as VMs das séries DS e GS.
As VMs de alta escala estão disponíveis em diferentes tamanhos com diferentes números de núcleos de CPU, memória, sistema operacional e tamanho de disco temporário. Cada tamanho de VM também tem um número máximo de discos de dados que você pode anexar à VM. O tamanho de VM escolhido afeta a quantidade de capacidade de armazenamento, processamento e memória disponível para o aplicativo. Ele também afeta o custo da computação e do armazenamento. Por exemplo, as especificações a seguir destinam-se ao maior tamanho de VM das séries DS e GS.
| Tamanho da VM | Núcleos de CPU | Memória | Tamanhos de disco da VM | Discos de dados máximos | Tamanho do cache | IOPS | Limites de E/S do cache da largura de banda |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | SO = 1.023 GB SSD local = 224 GB |
32 | 576 GB | 50.000 IOPS 512 MB/s |
4.000 IOPS e 33 MB/s |
| Standard_GS5 | 32 | 448 GB | SO = 1.023 GB SSD local = 896 GB |
64 | 4224 GB | 80.000 IOPS 2.000 MB/s |
5.000 IOPS e 50 MB/s |
Para ver uma lista completa de todos os tamanhos disponíveis de VM do Azure, confira Tamanhos de máquinas virtuais do Azure. Escolha um tamanho de VM que possa atender aos requisitos de desempenho de aplicativo desejados. Também leve em conta as considerações importantes a seguir ao escolher os tamanhos de VM.
Limites de escala
Os limites máximos de IOPS por VM e por disco são diferentes e independentes um do outro. Verifique se o aplicativo gera a IOPS dentro dos limites da VM e dos discos premium anexados a ela. Caso contrário, o desempenho do aplicativo será limitado.
Por exemplo, suponha que o requisito de um aplicativo seja de 4.000 IOPS. Para chegar a esse nível, você provisiona um disco P30 em uma VM DS1. O disco P30 pode oferecer até 5.000 IOPS. No entanto, a VM DS1 é limitada a 3.200 IOPS. Portanto, o desempenho do aplicativo é restringido pelo limite de VM em 3.200 IOPS e o desempenho é degradado. Para evitar essa situação, escolha um tamanho de disco e de VM que atenda aos requisitos do aplicativo.
Custo da operação
Em muitos casos, é possível que o custo geral de operação com o Armazenamento Premium seja menor do que com o Armazenamento Standard.
Por exemplo, considere um aplicativo que exija 16.000 IOPS. Para atingir esse desempenho, você precisa de uma VM de IaaS Standard_D14 do Azure que possa fornecer um máximo de 16.000 IOPS usando 32 discos de Armazenamento Standard de 1 TB. Cada disco de armazenamento padrão de 1 TB pode atingir um máximo de 500 IOPS.
- O custo estimado dessa VM por mês é de US$ 1.570.
- O custo mensal de 32 discos de Armazenamento Standard é de US$ 1.638.
- O custo total mensal estimado é de US$ 3.208.
Se você tiver hospedado o mesmo aplicativo no Armazenamento Premium, precisará de uma VM menor e de menos discos do Armazenamento Premium, reduzindo o custo geral. Uma VM Standard_DS13 pode atender ao requisito de 16.000 IOPS usando quatro discos P30. A VM DS13 tem um máximo de 25.600 IOPS, e cada disco P30 tem um máximo de 5.000 IOPS. Em geral, essa configuração pode alcançar 5.000 x 4 = 20.000 IOPS.
- O custo estimado dessa VM por mês é de US$ 1.003.
- O custo mensal de quatro discos P30 do Armazenamento Premium é de US$ 544,34.
- O custo total mensal estimado é de US$ 1.544.
A tabela a seguir resume o detalhamento do custo desse cenário no Armazenamento Premium e Standard.
| Custo mensal | Standard | Premium |
|---|---|---|
| Custo de VM por mês | US$ 1.570,58 (Standard_D14) | US$ 1.003,66 (Standard_DS13) |
| Custo de discos por mês | US$ 1.638,40 (32 discos x 1 TB) | US$ 544,34 (4 discos x P30) |
| Custo geral por mês | US$ 3.208,98 | US$ 1.544,34 |
Distribuições do Linux
Com o Armazenamento Premium, você obtém o mesmo nível de desempenho nas VMs que executam o Windows e o Linux. Damos suporte a muitas variantes de distribuições Linux. Para saber mais, confira Distribuições do Linux endossadas no Azure.
Distribuições diferentes são mais adequadas para tipos distintos de carga de trabalho. Você verá diferentes níveis de desempenho dependendo da distribuição em que a carga de trabalho está sendo executada. Teste as distribuições Linux com seu aplicativo e escolha a mais adequada.
Ao executar o Linux com o Armazenamento Premium, verifique as últimas atualizações dos drivers necessários para garantir o alto desempenho.
Tamanhos de disco do armazenamento Premium
O Armazenamento Premium oferece vários tamanhos para que você possa escolher um que melhor atenda às suas necessidades. Cada tamanho de disco tem um limite de escala diferente para IOPS, largura de banda e armazenamento. Escolha o tamanho certo de disco do Armazenamento Premium de acordo com os requisitos do aplicativo e o tamanho de VM de alta escala. A tabela a seguir mostra os três tamanhos de disco e as respectivas funcionalidades. Atualmente, só há suporte aos tamanhos de disco P4, P6, P15, P60, P70 e P80 no Managed Disks.
| Tamanhos de unidades SSD Premium | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Tamanho do disco em GiB | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1\.024 | 2\.048 | 4\.096 | 8\.192 | 16.384 | 32.767 |
| IOPS provisionada base 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 provisionada expandida 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 |
| Taxa de transferência provisionada base 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 |
| **Taxa de transferência provisionada expandida 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 intermitência por disco | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 30.000* | 30.000* | 30.000* | 30.000* | 30.000* | 30.000* |
| Taxa de transferência de intermitência máxima 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 | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* |
| Duração máxima da intermitência | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | Ilimitado* | Ilimitado* | Ilimitado* | Ilimitado* | Ilimitado* | Ilimitado* |
| Qualificado para reserva | Não | No | No | No | No | No | No | Não | Sim, até um ano | Sim, até um ano | Sim, até um ano | Sim, até um ano | Sim, até um ano | Sim, até um ano |
*Aplica-se somente a discos com o bursting sob demanda habilitado.
** Aplica-se apenas a discos com o desempenho extra (prévia) ativado.
Quantos discos você escolhe depende do tamanho do disco escolhido. Você pode usar um único disco P50 ou vários discos P10 para atender aos requisitos do aplicativo. Leve em conta as considerações listadas aqui ao fazer sua escolha.
Limites de escala (IOPS e taxa de transferência)
Os limites de IOPS e taxa de transferência de cada tamanho de disco premium são diferentes e independentes dos limites de escala da VM. Verifique se o total de IOPS e taxa de transferência dos discos está dentro dos limites de escala do tamanho escolhido de VM.
Por exemplo, se o requisito de um aplicativo for de, no máximo, 250 MB/s de taxa de transferência e você estiver usando uma VM DS4 com um só disco P30, a VM DS4 poderá fornecer uma taxa de transferência de até 256 MB/s. No entanto, um disco P30 tem um limite de taxa de transferência de 200 MB/s. Portanto, o aplicativo é restrito a 200 MB/s, devido ao limite de disco. Para superar esse limite, provisione mais de um disco de dados à VM ou redimensione seus discos para P40 ou P50.
Observação
As leituras atendidas pelo cache não estão incluídas na IOPS e na taxa de transferência do disco, portanto, não estão sujeitas aos limites de disco. O cache tem um limite de IOPS e taxa de transferência separado por VM.
Por exemplo, inicialmente, as leituras e as gravações são de 60 MB/s e 40 MB/s, respectivamente. Ao longo do tempo, o cache aquece e atende cada vez mais leituras no cache. Assim, você pode obter uma taxa de transferência de gravação mais alta do disco.
Número de discos
Determine o número de discos de que você precisa avaliando os requisitos do aplicativo. Cada tamanho de VM também tem um limite de número de discos que você pode anexar à VM. Normalmente, esse valor é duas vezes o número de núcleos. Verifique se o tamanho de VM que você escolheu pode oferecer suporte ao número de discos necessário.
Lembre-se de que os discos do Armazenamento Premium têm funcionalidades de desempenho mais alto comparado aos discos do Armazenamento Standard. Se estiver migrando seu aplicativo de uma VM de IaaS do Azure que usa o Armazenamento Standard para o Armazenamento Premium, será provável que você precisará de menos discos premium para atingir um desempenho igual ou mais alto no aplicativo.
Cache de disco
As VMs de alta escala que usam o Armazenamento Premium têm uma tecnologia de cache de várias camadas chamada BlobCache. O BlobCache usa uma combinação de RAM do host e SSD local para o cache. Esse cache está disponível para os discos persistentes do Armazenamento Premium e os discos locais da VM. Por padrão, essa configuração de cache é definida como ReadWrite para os discos do sistema operacional e ReadOnly para os discos de dados hospedados no Armazenamento Premium. Com o cache de disco habilitado nos discos do Armazenamento Premium, as VMs de alta escala podem atingir níveis extremamente altos de desempenho que excedem o desempenho do disco subjacente.
Aviso
O cache de disco não é compatível com discos de 4 TiB e maiores. Se vários discos estiverem anexados à VM, cada disco com menos de 4 TiB dará suporte ao cache.
A alteração da configuração de cache de um disco do Azure desanexa e anexa novamente o disco de destino. Se ele for o disco do sistema operacional, a VM será reiniciada. Pare todos os aplicativos e serviços que podem ser afetados por essa interrupção antes de alterar a configuração de cache do disco. Não seguir essas recomendações pode gerar dados corrompidos.
Para saber mais sobre como o BlobCache funciona, confira a postagem no blog interno Armazenamento Premium do Azure.
É importante habilitar o cache no conjunto certo de discos. Se você deve habilitar o cache de disco em um disco premium ou não depende do padrão da carga de trabalho que o disco processa. A tabela a seguir mostra as configurações padrão de cache para os discos do sistema operacional e de dados.
| Tipo de disco | Configuração padrão de cache |
|---|---|
| Disco do sistema operacional | ReadWrite |
| Disco de dados | ReadOnly |
Recomendamos as configurações de cache de disco a seguir para discos de dados.
| Configuração do cache de disco | Recomendação sobre quando usar essa configuração |
|---|---|
| Nenhum | Configure o cache do host como None para discos com uso intensivo de gravação e somente gravação. |
| ReadOnly | Configure o cache do host como ReadOnly para discos de leitura/gravação e somente leitura. |
| ReadWrite | Configure o cache do host como ReadWrite somente se o aplicativo processa corretamente a gravação de dados armazenados em cache em discos persistentes quando necessário. |
ReadOnly (somente-leitura)
Ao configurar o cache ReadOnly em discos de dados do Armazenamento Premium, você pode obter uma baixa latência de leitura e uma IOPS de leitura e uma taxa de transferência muito altas para seu aplicativo por dois motivos:
- As leituras feitas no cache, que está na memória da VM e no SSD local, são mais rápidas do que as leituras no disco de dados, que está no Armazenamento de Blobs do Azure.
- O Armazenamento Premium não leva as leituras atendidas no cache em conta para definir a IOPS e a taxa de transferência do disco. Por esse motivo, seu aplicativo pode obter um total de IOPS e taxa de transferência mais altos.
ReadWrite
Por padrão, os discos do sistema operacional têm o cache ReadWrite habilitado. Recentemente, adicionamos suporte ao cache ReadWrite também nos discos de dados. Se estiver usando o cache ReadWrite, você precisará ter uma forma adequada de gravar os dados do cache nos discos persistentes. Por exemplo, o SQL Server manipula a gravação de dados em cache nos discos de armazenamento persistentes por sua própria conta. Usar o cache ReadWrite com um aplicativo que não processa a persistência dos dados necessários pode levar à perda de dados, no caso de falha da VM.
Nenhum
Atualmente, Nenhum só tem suporte em discos de dados. Não há suporte a ele nos discos do sistema operacional. Se você definir None em um disco do sistema operacional, ele substituirá essa configuração internamente e a definirá como ReadOnly.
Por exemplo, você pode aplicar essas diretrizes ao SQL Server em execução no Armazenamento Premium seguindo estas etapas:
- Configure o cache ReadOnly nos discos do Armazenamento Premium que hospedam arquivos de dados.
- As leituras rápidas no cache reduzem o tempo de consulta do SQL Server, pois as páginas de dados são recuperadas de maneira mais rápida do cache do que diretamente dos discos de dados.
- Atender às leituras no cache significa que há mais taxa de transferência disponível nos discos de dados premium. O SQL Server pode usar essa taxa de transferência extra para recuperar mais páginas de dados e outras operações, como backup/restauração, cargas em lote e recompilações de índice.
- Configure o cache None nos discos do Armazenamento Premium que hospedam os arquivos de log.
- Os arquivos de log têm principalmente operações com uso intensivo de gravação, portanto, não se beneficiam do cache ReadOnly.
Otimizar o desempenho em VMs Linux
Em todos os SSDs Premium ou Discos Ultra, você poderá desabilitar as barreiras de sistemas de arquivos no disco, a fim de aprimorar o desempenho, quando souber que nenhum cache poderá perder dados. Se o cache de disco do Azure for definido como ReadOnly ou None, será possível desabilitar as barreiras. Mas se o cache for definido como ReadWrite, as barreiras deverão permanecer habilitadas para garantir a durabilidade da gravação. Em geral, as barreiras estão habilitadas por padrão, porém, é possível desabilitá-las usando um dos seguintes métodos dependendo do tipo de sistema de arquivos:
- reiserFS: use a opção de montagem barrier=none para desabilitar as barreiras. Use barrier=flush para habilitar as barreiras de modo explícito.
- ext3/ext4: use a opção de montagem barrier=0 para desabilitar as barreiras. Use barrier=1 para habilitar as barreiras de modo explícito.
- XFS: use a opção de montagem nobarrier para desabilitar as barreiras. Use barrier para habilitar as barreiras de modo explícito. A partir da versão 4.10 do kernel principal do Linux, o design do sistema de arquivos XFS sempre garante a durabilidade. A desabilitação de barreiras não tem efeito e a opção nobarrier foi preterida. No entanto, algumas distribuições do Linux podem ter feito backport das alterações em uma versão de distribuição com uma versão anterior do kernel. Verifique com o fornecedor de distribuição o status na distribuição e na versão que você está executando.
Distribuição de discos
Quando uma VM de alta escala é anexada com vários discos persistentes do Armazenamento Premium, os discos podem ser distribuídos em conjunto para agregar a respectiva capacidade de armazenamento, IOPS e largura de banda.
No Windows, você pode usar Espaços de Armazenamento para dividir discos em conjunto. É preciso configurar uma coluna para cada disco em um pool. Caso contrário, o desempenho geral do volume distribuído pode ser menor que o esperado, devido a uma distribuição irregular do tráfego entre os discos.
Usando a interface do usuário do Gerenciador do Servidor, defina o número total de colunas em até 8 para um volume distribuído. Ao anexar mais de oito discos, use o PowerShell para criar o volume. Usando o PowerShell, é possível definir o número de colunas como igual ao número de discos. Por exemplo, se houver 16 discos em um só conjunto de distribuição, especifique 16 colunas no parâmetro NumberOfColumns do cmdlet New-VirtualDisk do PowerShell.
No Linux, use o utilitário MDADM para distribuir os discos em conjunto. Para ver as etapas sobre como distribuir discos no Linux, confira Configurar o RAID de software no Linux.
Tamanho da distribuição
Uma configuração importante na distribuição de disco é o tamanho dela. O tamanho da distribuição ou o tamanho do bloco é a menor parte de dados que o aplicativo pode incluir em um volume distribuído. O tamanho da distribuição que você configura depende do tipo de aplicativo e de seu padrão de solicitação. Se você escolher o tamanho de distribuição errado, isso poderá levar ao alinhamento incorreto de E/S, o que resulta na degradação de desempenho do aplicativo.
Por exemplo, se uma solicitação de E/S gerada pelo aplicativo for maior que o tamanho da distribuição do disco, o sistema de armazenamento a gravará entre os limites de unidade de distribuição em mais de um disco. Quando for a hora de acessar esses dados, ele precisará procurar em mais de uma unidade de distribuição para concluir a solicitação. O efeito cumulativo de tal comportamento pode levar à degradação substancial de desempenho. Por outro lado, se o tamanho da solicitação de E/S for menor que o tamanho da distribuição e se ela for de natureza aleatória, as solicitações de E/S poderão ser adicionadas no mesmo disco, causando um gargalo e, por fim, a degradação do desempenho de E/S.
De acordo com o tipo de carga de trabalho que o aplicativo está executando, escolha um tamanho de distribuição apropriado. Para solicitações pequenas e aleatórias de E/S, use um tamanho de distribuição menor. Para solicitações de E/S grandes e sequenciais, use um tamanho de distribuição maior. Descubra as recomendações de tamanho de distribuição para o aplicativo que você executará no Armazenamento Premium. Para o SQL Server, configure um tamanho de distribuição de 64 kb para cargas de trabalho OLTP e de 256 KB para cargas de trabalho de data warehouse. Para obter mais informações, confira Melhores práticas de desempenho do SQL Server em VMs do Azure.
Observação
você pode usar a distribuição com um máximo de 32 discos do armazenamento premium em uma VM série DS e 64 discos do armazenamento premium em uma VM série GS.
Multithreading
O Azure projetou a plataforma Armazenamento Premium para ser extremamente paralela. Por esse motivo, um aplicativo multi-threaded atinge um desempenho muito mais alto do que um aplicativo de thread único. Um aplicativo multi-threaded divide as tarefas entre vários threads e aumenta a eficiência da execução utilizando, ao máximo, os recursos de VM e de disco.
Por exemplo, se o aplicativo estiver em execução em uma VM de único núcleo usando dois threads, a CPU poderá alternar entre os dois threads para obter eficiência. Enquanto um thread está aguardando a conclusão da E/S de um disco, a CPU pode alternar para o outro thread. Dessa forma, dois threads podem fazer mais do que um único thread. Se a VM tiver mais de um núcleo, ela diminuirá ainda mais o tempo de execução, pois cada núcleo pode executar tarefas em paralelo.
Talvez você possa alterar a forma como um aplicativo pronto para uso implementa o thread único ou o multithreading. Por exemplo, o SQL Server tem a capacidade de processar várias CPUs e vários núcleos. No entanto, o SQL Server decide as condições nas quais ele usa um ou mais threads para processar uma consulta. Ele pode executar consultas e criar índices usando o multithreading. Para uma consulta que envolva a união de tabelas grandes e a classificação de dados antes do retorno ao usuário, é provável que o SQL Server use vários threads. Um usuário não pode controlar o fato de o SQL Server executar uma consulta usando um só thread ou vários deles.
Há definições de configuração que você pode alterar para influenciar o multithreading ou o processamento paralelo de um aplicativo. Por exemplo, no caso do SQL Server, essa é a configuração max degree of parallelism. Essa configuração chamada MAXDOP permite que você configure o número máximo de processadores que o SQL Server pode usar no processamento paralelo. É possível configurar MAXDOP para consultas individuais ou operações de índice. Essa capacidade é útil quando você deseja equilibrar recursos os do sistema para um aplicativo crítico de desempenho.
Por exemplo, digamos que o seu aplicativo que usa o SQL Server está executando uma consulta grande e uma operação de índice ao mesmo tempo. Vamos supor que você deseje que a operação de índice tenha um desempenho melhor do que a consulta grande. Nesse caso, você pode definir o valor MAXDOP da operação de índice como maior que o valor MAXDOP da consulta. Dessa forma, o SQL Server tem mais processadores que pode usar para a operação de índice comparado ao número de processadores que pode dedicar à consulta grande. Lembre-se de que você não controla o número de threads que o SQL Server usa para cada operação. É possível controlar o número máximo de processadores que está sendo dedicado ao multithreading.
Saiba mais sobre os graus de paralelismo no SQL Server. Descubra como essas configurações influenciam o multithreading no aplicativo e as respectivas configurações para otimizar o desempenho.
Profundidade da fila
A profundidade da fila, comprimento da fila ou tamanho da fila é o número de solicitações de E/S pendentes no sistema. O valor da profundidade da fila determina quantas operações de E/S o aplicativo pode alinhar, as quais os discos de armazenamento processam. Isso afeta os três indicadores de desempenho de aplicativo que abordamos neste artigo: IOPS, taxa de transferência e latência.
A profundidade da fila e o multithreading estão intimamente relacionados. O valor de profundidade da fila indica quanto multithreading pode ser obtido pelo aplicativo. Se a profundidade da fila for grande, o aplicativo poderá executar mais operações simultaneamente. Em outras palavras, mais multithreading. Se a profundidade da fila for pequena, mesmo que o aplicativo seja multi-threaded, ele não terá solicitações suficientes alinhadas para execução simultânea.
Normalmente, os aplicativos prontos para uso não permitem que você altere a profundidade da fila, pois se ela for definida incorretamente, fará mais mal do que bem. Os aplicativos definem o valor correto da profundidade da fila para obter o desempenho ideal. É importante entender esse conceito para solucionar problemas de desempenho com o aplicativo. Também é possível observar os efeitos da profundidade da fila executando ferramentas de parâmetros de comparação no sistema.
Alguns aplicativos fornecem configurações para influenciar a profundidade da fila. Por exemplo, a configuração MAXDOP do SQL Server explicada na seção anterior. MAXDOP é uma forma de influenciar a profundidade da fila e o multithreading, embora isso não altere diretamente o valor da profundidade da fila do SQL Server.
Profundidade alta de fila
Uma profundidade alta de fila alinha mais operações no disco. O disco sabe da próxima solicitação na fila antecipadamente. Portanto, o disco pode agendar operações com antecedência e processá-las em uma sequência ideal. Como o aplicativo envia mais solicitações ao disco, o disco pode processar mais E/Ss paralelas. Por fim, o aplicativo pode obter uma IOPS mais alta. Como o aplicativo processa mais solicitações, a taxa de transferência total dele também aumenta.
Normalmente, um aplicativo pode atingir a taxa máxima de transferência com 8 a pouco mais de 16 E/Ss pendentes por disco anexado. Se uma profundidade de fila é um, o aplicativo não envia uma E/S suficiente ao sistema e ele processa uma quantidade menor em determinado período. Em outras palavras, uma taxa de transferência menor.
Por exemplo, no SQL Server, configurar o valor MAXDOP de uma consulta como 4 informa ao SQL Server que ele pode usar até quatro núcleos para executar a consulta. O SQL Server determina o melhor valor de profundidade da fila e o número de núcleos para a execução da consulta.
Profundidade ideal de fila
Um valor muito alto de profundidade da fila também traz desvantagens. Se o valor de profundidade da fila for muito alto, o aplicativo tentará gerar uma IOPS muito alta. A menos que o aplicativo tenha discos persistentes com IOPS suficiente provisionada, um valor de profundidade de fila muito alto pode afetar negativamente as latências do aplicativo. A fórmula a seguir mostra a relação entre IOPS, latência e profundidade da fila.
Você não deve configurar a profundidade da fila para um valor alto, mas para um valor ideal, que possa fornecer IOPS suficiente ao aplicativo sem afetar as latências. Por exemplo, se a latência do aplicativo precisa ser de 1 milissegundo, a profundidade da fila necessária para alcançar 5.000 IOPS será QD = 5.000 x 0,001 = 5.
Profundidade da fila para um volume distribuído
Para um volume distribuído, mantenha uma profundidade de fila alta o suficiente, de modo que cada disco tenha uma profundidade de fila de pico individualmente. Por exemplo, considere um aplicativo que envia uma profundidade de fila igual a 2 e tenha quatro discos na distribuição. As duas solicitações de E/S são encaminhadas para dois discos, e os dois discos restantes ficam ociosos. Portanto, configure a profundidade da fila para que todos os discos possam ficar ocupados. A fórmula a seguir mostra como determinar a profundidade da fila de volumes distribuídos.
Limitação
O Armazenamento Premium provisiona um número especificado de IOPS e taxa de transferência, dependendo dos tamanhos de VM e de disco escolhidos. Sempre que o aplicativo tentar gerar uma IOPS ou uma taxa de transferência acima desses limites que a VM ou o disco pode processar, o Armazenamento Premium o limitará. O resultado é um desempenho degradado no aplicativo, o que pode significar maior latência, menor taxa de transferência ou IOPS mais baixa.
Se o Armazenamento Premium não limitá-lo, o aplicativo poderá falhar por completo, excedendo o que os recursos podem obter. Para evitar problemas de desempenho devido à limitação, sempre provisione recursos suficientes ao aplicativo. Leve em consideração o que abordamos nas seções anteriores sobre tamanhos de disco e de VM. Os parâmetros de comparação são a melhor maneira de entender os recursos de que você precisará para hospedar seu aplicativo.
Próximas etapas
Caso pretenda avaliar o desempenho do disco, confira os seguintes artigos:
- No Linux: submeter seu aplicativo a benchmark no Armazenamento em Disco do Azure
- No Windows: Avaliar o desempenho de um disco
Saiba mais sobre os tipos de disco disponíveis:
- No Linux: selecione um tipo de disco
- No Windows: selecione um tipo de disco
Para usuários do SQL Server, leia os artigos sobre melhores práticas de desempenho do SQL Server: