Armazenamento Premium do Azure: Conceção para elevado desempenho
Aplica-se a: ✔️ VMs ✔️ Linux VMs ✔️ do Windows Conjuntos ✔️ de escala flexíveis Conjuntos de balanças uniformes
Este artigo fornece diretrizes para criar 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 seu aplicativo. Para ilustrar as diretrizes, usamos o SQL Server em execução no armazenamento premium como exemplo ao longo deste documento.
Embora abordemos cenários de desempenho para a camada de armazenamento neste artigo, você precisa otimizar a camada de aplicativo. Por exemplo, se você estiver hospedando um farm do SharePoint em armazenamento premium, poderá usar os exemplos do SQL Server deste artigo para otimizar o servidor de banco de dados. Você também pode otimizar o servidor Web e o servidor de aplicativos do Farm do SharePoint para obter o máximo desempenho.
Este artigo ajuda a responder às seguintes perguntas comuns sobre como otimizar o desempenho do aplicativo no armazenamento premium:
- Como você pode medir o desempenho do seu 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 seu aplicativo no armazenamento premium?
- Como você pode otimizar as operações de entrada/saída por segundo (IOPS), largura de banda e latência?
Fornecemos essas diretrizes especificamente para armazenamento premium porque as cargas de trabalho executadas em armazenamento premium são altamente sensíveis ao desempenho. Fornecemos exemplos quando apropriado. Você também pode aplicar algumas dessas diretrizes a aplicativos executados em VMs IaaS (infraestrutura como serviço) com discos de armazenamento padrão.
Nota
Às vezes, o que parece ser um problema de desempenho de disco é, na verdade, um gargalo de rede. Nessas situações, você deve otimizar o desempenho da rede.
Se você estiver procurando fazer benchmarking do seu disco, consulte os seguintes artigos:
- Para Linux: faça benchmark do seu aplicativo no Armazenamento em Disco do Azure
- Para Windows: Avaliar comparativamente um disco
Se a sua VM suportar rede acelerada, certifique-se de que está ativada. Se ele não estiver habilitado, você poderá habilitá-lo em VMs já implantadas no Windows e no Linux.
Antes de começar, se você for novo no armazenamento premium, leia primeiro Selecione um tipo de disco do Azure para VMs IaaS e Destinos de escalabilidade para contas de armazenamento de blob de página premium.
Indicadores de desempenho da aplicação
Avaliamos se um aplicativo está tendo um bom desempenho ou não usando indicadores de desempenho como:
- Quão rápido um aplicativo está processando uma solicitação do usuário.
- Quantos dados um aplicativo está processando por solicitação.
- Quantos pedidos um pedido está a processar num período de tempo específico.
- Quanto tempo um usuário tem que esperar para obter uma resposta depois de enviar sua 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, discutimos os indicadores de desempenho comuns no contexto do armazenamento premium. Na seção Lista de verificação do aplicativo de desempenho para discos, você aprenderá a medir esses indicadores de desempenho para seu aplicativo. Mais tarde, em Otimizar o desempenho do aplicativo, você aprenderá sobre os fatores que afetam esses indicadores de desempenho e recomendações para otimizá-los.
IOPS
IOPS é o número de solicitações que seu aplicativo está enviando para discos de armazenamento em um segundo. Uma operação de entrada/saída pode ser lida ou escrita, sequencial ou aleatória. Os aplicativos de processamento de transações on-line (OLTP), como um site de varejo on-line, precisam processar muitas solicitações de usuários simultâneos imediatamente. As solicitações do usuário são transações de banco de dados com uso intensivo de inserção e atualização, que o aplicativo deve processar rapidamente. Por esse motivo, os aplicativos OLTP exigem IOPS muito altas.
Os aplicativos OLTP lidam com milhões de solicitações de E/S pequenas e aleatórias. Se você tiver esse aplicativo, deverá projetar a infraestrutura do aplicativo para otimizar o IOPS. Para obter mais informações sobre todos os fatores a serem considerados para obter IOPS altas, consulte Otimizar o desempenho do aplicativo.
Quando você anexa um disco de armazenamento premium à sua VM de alta escala, o Azure provisiona para você 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 de IOPS específico que pode sustentar. Por exemplo, uma VM Standard GS5 tem um limite de 80 000 IOPS.
Débito
Taxa de transferência, ou largura de banda, é a quantidade de dados que seu aplicativo está enviando para os discos de armazenamento em um intervalo especificado. Se seu aplicativo estiver executando operações de entrada/saída com grandes tamanhos de unidade de E/S, ele exigirá alta taxa de transferência. Os aplicativos de data warehouse tendem a emitir operações de varredura intensiva que acessam grandes porções de dados de cada vez e geralmente executam operações em massa. Em outras palavras, tais aplicativos exigem maior taxa de transferência. Se você tiver um aplicativo desse tipo, deverá projetar sua infraestrutura para otimizar a taxa de transferência. Na próxima seção, discutiremos os fatores que você deve ajustar para alcançar essa otimização.
Quando você anexa um disco de armazenamento premium a uma VM de alta escala, o Azure provisiona a taxa de transferência de acordo com essa especificação de disco. Por exemplo, um disco P50 provisiona uma taxa de transferência de disco de 250 MB/seg. Cada tamanho de VM de alta escala também tem um limite de taxa de transferência específico que pode sustentar. Por exemplo, a VM GS5 padrão tem uma taxa de transferência máxima de 2.000 MB/seg.
Há uma relação entre taxa de transferência e IOPS, conforme mostrado na fórmula a seguir.
É importante determinar a taxa de transferência ideal e os valores de IOPS que seu aplicativo exige. À medida que você tenta otimizar um, o outro também é afetado. Para obter mais informações sobre como otimizar IOPS e taxa de transferência, consulte Otimizar o desempenho do aplicativo.
Latência
Latência é o tempo que um aplicativo leva para receber uma única solicitação, enviá-la para discos de armazenamento e enviar a resposta para o cliente. A latência é uma medida crítica do desempenho de um aplicativo, além de IOPS e taxa de transferência. A latência de um disco de armazenamento premium é o tempo necessário para recuperar as informações de uma solicitação e comunicá-las de volta ao seu aplicativo. O armazenamento Premium fornece latências consistentemente baixas. Os discos Premium são projetados para fornecer latências de milissegundos de um dígito para a maioria das operações de E/S. Se você habilitar o cache de host ReadOnly em discos de armazenamento premium, poderá obter uma latência de leitura muito menor. Para obter mais informações sobre cache de disco, consulte Cache de disco.
Quando você otimiza seu aplicativo para obter IOPS e taxa de transferência mais altas, isso afeta a latência do seu aplicativo. Depois de ajustar o desempenho do aplicativo, avalie a latência do aplicativo para evitar um comportamento inesperado de alta latência.
Algumas operações de plano de controle em discos gerenciados podem mover o disco de um local de armazenamento para outro. A movimentação do disco entre locais de armazenamento é orquestrada por meio de uma cópia em segundo plano dos dados, que pode levar várias horas para ser concluída. Normalmente, o tempo é inferior a 24 horas, dependendo da quantidade de dados nos discos. Durante esse tempo, seu aplicativo pode experimentar latência de leitura maior do que o normal, porque algumas leituras podem ser redirecionadas para o local original e levar mais tempo para serem concluídas.
Durante uma cópia em segundo plano, não há efeito na latência de gravação para a maioria dos tipos de disco. Para SSD Premium v2 e Ultra Disks, se o disco tiver um tamanho de setor 4K, ele experimenta maior latência de leitura. Se o disco tiver um tamanho de setor 512e, ele experimenta maior latência de leitura e gravação.
As seguintes operações do plano de controle podem mover o disco entre locais de armazenamento e causar maior latência:
- Atualize o tipo de armazenamento.
- Desanexe e anexe um disco de uma VM a outra.
- Crie um disco gerenciado a partir de um VHD.
- Crie um disco gerenciado a partir de um snapshot.
- Converta discos não gerenciados em discos gerenciados.
Lista de verificação do aplicativo de desempenho para discos
A primeira etapa no projeto de aplicativos de alto desempenho executados em armazenamento premium é entender os requisitos de desempenho do seu aplicativo. Depois de reunir os requisitos de desempenho, você pode otimizar seu 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 críticos para seu aplicativo para oferecer a experiência de usuário desejada. Por exemplo, IOPS altas são mais importantes para aplicativos OLTP que processam milhões de transações em um segundo. A alta taxa de transferência é crítica para aplicativos de data warehouse que processam grandes quantidades de dados em um segundo. A latência extremamente baixa é crucial para aplicações em tempo real, como sites de streaming de vídeo ao vivo.
Em seguida, meça os requisitos máximos de desempenho do seu aplicativo ao longo de sua vida útil. Use a lista de verificação de exemplo a seguir como um começo. Registre os requisitos máximos de desempenho durante períodos de carga de trabalho normais, de pico e fora do horário. Ao identificar os requisitos para todos os níveis de carga de trabalho, você pode determinar o requisito geral de desempenho do seu aplicativo.
Por exemplo, a carga de trabalho normal de um site de comércio eletrônico são as transações que ele atende durante a maioria dos dias de um ano. O pico de carga de trabalho do site são as transações que ele serve durante as temporadas de férias ou eventos especiais de venda. A carga de trabalho de pico normalmente é experimentada por um período limitado, mas pode exigir que seu aplicativo seja dimensionado duas ou mais vezes sua operação normal. Descubra os requisitos de percentil 50, percentil 90 e percentil 99. Essas informações ajudam a filtrar quaisquer discrepâncias nos requisitos de desempenho, e você pode concentrar seus esforços na otimização para os valores certos.
Lista de verificação de requisitos de desempenho do aplicativo
| Requisitos de desempenho | Percentil 50 | percentil 90 | percentil 99 |
|---|---|---|---|
| Máximo de transações por segundo | |||
| % Operações de leitura | |||
| % Operações de gravação | |||
| % Operações aleatórias | |||
| % Operações sequenciais | |||
| Tamanho da solicitação de E/S | |||
| Rendimento médio | |||
| Débito máximo | |||
| Latência mínima | |||
| Latência média | |||
| CPU máxima | |||
| Média da CPU | |||
| Máximo de memória | |||
| Memória média | |||
| Profundidade da fila |
Nota
Considere dimensionar esses números com base no crescimento futuro esperado do seu aplicativo. É uma boa ideia planejar o crescimento com antecedência, pois pode ser mais difícil alterar a infraestrutura para melhorar o desempenho mais tarde.
Se você tiver um aplicativo existente e quiser mudar para o armazenamento premium, primeiro crie a lista de verificação anterior para o aplicativo existente. Em seguida, crie um protótipo do seu aplicativo no armazenamento premium e projete o aplicativo com base nas diretrizes descritas em Otimizar o desempenho do aplicativo. O próximo artigo descreve as ferramentas que você pode usar para reunir as medições de desempenho.
Contadores para medir os requisitos de desempenho do aplicativo
A melhor maneira de medir os requisitos de desempenho do seu aplicativo é usar PerfMonas ferramentas de monitoramento fornecidas pelo sistema operacional do servidor. Você pode usar PerfMon para Windows e iostat Linux. Essas ferramentas capturam contadores correspondentes a cada medida explicada na seção anterior. Você deve capturar os valores desses contadores quando seu aplicativo estiver executando suas cargas de trabalho normais, de pico e fora de horas.
Os PerfMon contadores estão disponíveis para processador, memória e cada disco lógico e disco físico do servidor. Quando você usa discos de armazenamento premium com uma VM, os contadores de disco físico são para cada disco de armazenamento premium e os contadores de disco lógico são para cada volume criado nos discos de armazenamento premium. Você deve capturar os valores para os 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 contadores de discos físicos. Caso contrário, consulte os contadores de disco lógico.
No Linux, o comando gera um relatório de utilização da CPU e do iostat disco. O relatório de utilização do disco fornece estatísticas por dispositivo físico ou partição. Se você tiver um servidor de banco de dados com seus dados e logs em discos separados, colete esses dados para ambos os discos. A tabela a seguir descreve contadores para discos, processadores e memória.
| Contador | Description | PerfMon | iostat |
|---|---|---|---|
| IOPS ou transações/seg | Número de solicitações de E/S emitidas para o disco de armazenamento/s | Leituras de disco/seg Gravações de disco/s |
TPS r/s c/s |
| Leituras e escritas do disco | % de operações de leitura e gravação realizadas no disco | % Tempo de leitura do disco % Tempo de gravação em disco |
r/s c/s |
| Débito | Quantidade de dados lidos ou gravados no disco/s | Bytes de leitura de disco/s Bytes de gravação de disco/s |
kB_read/s kB_wrtn/s |
| Latência | Tempo total para concluir uma solicitação de E/S de disco | Média de seg/leitura de disco Média de seg/gravação de disco |
aguardar SVCTM |
| Tamanho de E/S | O tamanho dos problemas de solicitação de E/S para os discos de armazenamento | Média de bytes/leitura de disco Média de bytes/gravação de disco |
AVGRQ-SZ |
| Profundidade da fila | Número de solicitações de E/S pendentes aguardando para serem lidas ou gravadas no disco de armazenamento | Comprimento atual da fila de discos | AVGQU-SZ |
| Máximo de memória | Quantidade de memória necessária para executar o aplicativo sem problemas | % Bytes confirmados em uso | Usar vmstat |
| CPU máxima | Quantidade de CPU necessária para executar o aplicativo sem problemas | % Tempo do processador | %util |
Saiba mais sobre iostat e PerfMon.
Otimize o desempenho do aplicativo
Os principais fatores que influenciam o desempenho de um aplicativo executado em 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 pode não oferecer uma opção para alterar o tamanho da E/S e a profundidade da fila diretamente. Por exemplo, se você estiver usando o SQL Server, não poderá escolher o tamanho da E/S e a profundidade da fila. O SQL Server escolhe o tamanho ideal de E/S e os valores de profundidade da fila para obter o máximo desempenho. É importante entender os efeitos de ambos os tipos de fatores no desempenho do aplicativo para que você possa provisionar recursos apropriados para atender às necessidades de desempenho.
Ao longo desta seção, consulte a lista de verificação de requisitos do aplicativo que você criou para identificar o quanto você precisa otimizar o desempenho do aplicativo. Com base na lista de verificação, você pode determinar quais fatores desta seção você precisa ajustar.
Para testemunhar os efeitos de cada fator no desempenho do aplicativo, execute ferramentas de benchmarking na configuração do aplicativo. Para conhecer as etapas para executar ferramentas comuns de benchmarking em VMs Windows e Linux, consulte os artigos de benchmarking no final deste documento.
Otimize rapidamente o IOPS, a taxa de transferência e a latência
A tabela a seguir resume os fatores de desempenho e as etapas necessárias para otimizar IOPS, taxa de transferência e latência. As seções que seguem este resumo descrevem cada fator com mais profundidade.
Para obter mais informações sobre tamanhos de VM e IOPS, taxa de transferência e latência disponíveis para cada tipo de VM, consulte Tamanhos para máquinas virtuais no Azure.
| Fatores de desempenho | IOPS | Débito | Latência |
|---|---|---|---|
| Cenário de exemplo | Aplicação OLTP empresarial que requer uma taxa de transações por segundo muito elevada. | Aplicação de armazenamento de dados empresariais que processa grandes quantidades de dados. | Aplicações quase em tempo real que requerem respostas instantâneas aos pedidos dos utilizadores, como jogos online. |
| Fatores de desempenho | |||
| Tamanho de E/S | Um tamanho de E/S menor produz IOPS mais altas. | Um tamanho de E/S maior produz uma taxa de transferência mais alta. | |
| Tamanho da VM | Use um tamanho de VM que ofereça IOPS maior do que o requisito do seu aplicativo. | Use um tamanho de VM com um limite de taxa de transferência maior do que o requisito do seu aplicativo. | Use um tamanho de VM que ofereça limites de escala maiores do que os requisitos do seu aplicativo. |
| Tamanho do disco | Use um tamanho de disco que ofereça IOPS maior do que o requisito do seu aplicativo. | Use um tamanho de disco com um limite de taxa de transferência maior do que o requisito do seu aplicativo. | Use um tamanho de disco que ofereça limites de escala maiores do que os requisitos do seu aplicativo. |
| Limites de escala de VM e disco | O limite de IOPS do tamanho da VM escolhido deve ser maior do que o total de IOPS controlado pelos discos de armazenamento conectados a ela. | O limite de taxa de transferência do tamanho da VM escolhido deve ser maior do que a taxa de transferência total gerada pelos discos de armazenamento premium conectados a ela. | Os limites de escala do tamanho da VM escolhido devem ser maiores do que os limites de escala total dos discos de armazenamento premium conectados. |
| Colocação em cache do disco | Habilite o cache somente leitura em discos de armazenamento premium com operações de leitura pesada para obter IOPS de leitura mais altas. | Habilite o cache ReadOnly em discos de armazenamento premium com operações de leitura pesada para obter latências de leitura muito baixas. | |
| Distribuição de disco | Use vários discos e distribua-os juntos para obter um limite de IOPS e taxa de transferência mais alto combinado. O limite combinado por VM deve ser maior do que os limites combinados de discos premium conectados. | ||
| Tamanho da risca | Tamanho de faixa menor para padrão de E/S pequeno aleatório visto em aplicativos OLTP. Por exemplo, use um tamanho de faixa de 64 KB para um aplicativo OLTP do SQL Server. | Tamanho de faixa maior para padrão de E/S sequencial grande visto em aplicativos de data warehouse. Por exemplo, use um tamanho de distribuição de 256 KB para um aplicativo de data warehouse do SQL Server. | |
| Multithreading | Use o multithreading para enviar um número maior de solicitações para o armazenamento premium para levar a 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 | Maior profundidade de fila produz IOPS mais altas. | Maior profundidade de fila produz maior taxa de transferência. | Menor profundidade de fila produz latências mais baixas. |
Natureza dos pedidos de E/S
Uma solicitação de E/S é uma unidade de operação de entrada/saída que seu aplicativo está executando. Identificar a natureza das solicitações de E/S, aleatórias ou sequenciais, de leitura ou gravação, pequenas ou grandes, ajuda a determinar os requisitos de desempenho do seu aplicativo. É importante entender a natureza das solicitações de E/S para tomar as decisões certas ao projetar sua infraestrutura de aplicativos. As E/S devem ser distribuídas uniformemente para obter o melhor desempenho possível.
O tamanho da 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 seu aplicativo. O tamanho da E/S afeta significativamente o desempenho, especialmente nas 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 seu tamanho de E/S, enquanto outros não. Por exemplo, o SQL Server determina o tamanho ideal de E/S em si e não fornece aos usuários nenhum botão para alterá-lo. Por outro lado, o Oracle fornece 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 você estiver usando um aplicativo que não permite alterar o tamanho da E/S, use as diretrizes deste artigo para otimizar o KPI de desempenho 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ções de E/S, você deve projetar sua infraestrutura de aplicativo para obter IOPS mais altas.
- Um aplicativo de armazenamento de dados gera solicitações de E/S grandes e sequenciais. Para lidar com esses tipos de solicitações de E/S, você deve projetar sua infraestrutura de aplicativo para obter maior largura de banda ou taxa de transferência.
Se você estiver usando um aplicativo que permite alterar o tamanho da E/S, use esta regra geral para o tamanho da E/S, além de outras diretrizes de desempenho:
- Tamanho de E/S menor para obter IOPS mais altas. Por exemplo, 8 KB para um aplicativo OLTP.
- Tamanho de E/S maior para obter maior largura de banda/taxa de transferência. Por exemplo, 1.024 KB para um aplicativo de data warehouse.
Aqui está um exemplo de como você pode calcular o IOPS e a taxa de transferência/largura de banda para seu aplicativo.
Considere um aplicativo que usa um disco P30. O máximo de IOPS e taxa de transferência/largura de banda que um disco P30 pode atingir é de 5.000 IOPS e 200 MB/seg, respectivamente. Se o seu aplicativo requer o máximo de IOPS do disco P30 e você usa um tamanho de E/S menor, como 8 KB, a largura de banda resultante que você pode obter é de 40 MB/seg. Se seu 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, o IOPS resultante será menor, como 200 IOPS.
Ajuste o tamanho da E/S para que ela atenda aos requisitos de IOPS e taxa de transferência/largura de banda do seu aplicativo. A tabela a seguir resume os diferentes tamanhos de E/S e suas IOPS e taxa de transferência correspondentes para um disco P30.
| Requisitos de candidatura | Tamanho de E/S | IOPS | Taxa de transferência/largura de banda |
|---|---|---|---|
| IOPS máximo | 8 KB | 5.000 | 40 MB/seg |
| Débito máximo | 1.024 KB | 200 | 200 MB/seg |
| Taxa de transferência máxima + IOPS alta | 64 KB | 3,200 | 200 MB/seg |
| IOPS máximo + alto rendimento | 32 KB | 5.000 | 160 MB/seg |
Para obter IOPS e largura de banda superiores ao valor máximo de um único disco de armazenamento premium, use vários discos premium distribuídos juntos. 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/seg. Conforme explicado na próxima seção, você deve usar um tamanho de VM que ofereça suporte ao IOPS e à taxa de transferência de disco combinados.
Nota
À medida que você aumenta o IOPS ou a taxa de transferência, o outro também aumenta. Certifique-se de não atingir os limites de taxa de transferência ou IOPS do disco ou da VM quando aumentar qualquer um deles.
Para testemunhar os efeitos do tamanho da E/S no desempenho do aplicativo, você pode executar ferramentas de benchmarking em sua VM e discos. Crie várias execuções de teste e use tamanhos de E/S diferentes para cada execução para ver o efeito. Para obter mais informações, consulte os artigos de benchmarking no final deste documento.
Tamanhos de VM de alta escala
Quando você começa a projetar um aplicativo, uma das primeiras coisas a fazer é escolher uma VM para hospedar seu aplicativo. O armazenamento Premium vem com tamanhos de VM de alta escala que podem executar aplicativos que exigem maior poder de computação e um alto desempenho de E/S de disco local. Essas VMs fornecem processadores mais rápidos, uma maior relação memória/núcleo e uma unidade de estado sólido (SSD) para o disco local. Exemplos de VMs de alta escala que suportam armazenamento premium são as VMs das séries DS e GS.
As VMs de alta escala estão disponíveis em tamanhos diferentes com um número diferente 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 da VM escolhido afeta a quantidade de processamento, memória e capacidade de armazenamento disponíveis para seu aplicativo. Isso também afeta o custo de computação e armazenamento. Por exemplo, as especificações a seguir são para o maior tamanho de VM em uma série DS e uma série 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 de cache de largura de banda |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | SO = 1.023 GB Local SSD = 224 GB |
32 | 576 GB | 50.000 IOPS 512 MB/seg |
4.000 IOPS e 33 MB/seg |
| Standard_GS5 | 32 | 448 GB | SO = 1.023 GB Local SSD = 896 GB |
64 | 4224 GB | 80.000 IOPS 2.000 MB/seg |
5.000 IOPS e 50 MB/seg |
Para exibir uma lista completa de todos os tamanhos de VM do Azure disponíveis, consulte Tamanhos para máquinas virtuais no Azure. Escolha um tamanho de VM que possa atender e dimensionar de acordo com os requisitos de desempenho do aplicativo desejados. Também leve em consideração as seguintes considerações importantes ao escolher tamanhos de VM.
Limites de escala
Os limites máximos de IOPS por VM e por disco são diferentes e independentes uns dos outros. Verifique se o aplicativo está gerando IOPS dentro dos limites da VM e dos discos premium conectados a ela. Caso contrário, o desempenho do aplicativo enfrenta limitação.
Como exemplo, suponha que um requisito de aplicativo seja um máximo de 4.000 IOPS. Para atingir esse nível, provisione um disco P30 em uma VM DS1. O disco P30 pode fornecer até 5.000 IOPS. No entanto, a VM DS1 está limitada a 3.200 IOPS. Assim, o desempenho do aplicativo é limitado pelo limite de VM em 3.200 IOPS e o desempenho é degradado. Para evitar essa situação, escolha uma VM e um tamanho de disco que atendam aos requisitos do aplicativo.
Custo de operação
Em muitos casos, é possível que seu custo total de operação usando armazenamento premium seja menor do que usando armazenamento padrão.
Por exemplo, considere um aplicativo que requer 16.000 IOPS. Para obter esse desempenho, você precisa de uma VM IaaS do Standard_D14 Azure, que pode fornecer um máximo de IOPS de 16.000 usando 32 discos de armazenamento padrão 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 padrão é de US$ 1.638.
- O custo mensal total estimado é de US$ 3.208.
Se você hospedou o mesmo aplicativo no armazenamento premium, precisará de um tamanho de VM menor e menos discos de 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 IOPS de 25.600 e cada disco P30 tem um máximo de IOPS de 5.000. No geral, essa configuração pode atingir 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 de armazenamento premium P30 é de US$ 544,34.
- O custo mensal total estimado é de US$ 1.544.
A tabela a seguir resume a divisão de custos desse cenário para armazenamento padrão e premium.
| Custo mensal | Standard | Premium |
|---|---|---|
| Custo da VM por mês | $1,570.58 (Standard_D14) | $1.003,66 (Standard_DS13) |
| Custo dos discos por mês | $1.638,40 (32 discos de 1 TB) | $544.34 (4 x discos P30) |
| Custo total por mês | $3,208.98 | $1,544.34 |
Distribuições Linux
Com o armazenamento premium, você obtém o mesmo nível de desempenho para VMs que executam Windows e Linux. Suportamos muitos sabores de distros Linux. Para obter mais informações, consulte Distribuições Linux endossadas no Azure.
Diferentes distros são mais adequadas para diferentes tipos de cargas de trabalho. Você vê diferentes níveis de desempenho, dependendo da distro na qual sua carga de trabalho está sendo executada. Teste as distribuições Linux com seu aplicativo e escolha a que funciona melhor.
Quando você executa o Linux com armazenamento premium, verifique as atualizações mais recentes sobre os drivers necessários para garantir o alto desempenho.
Tamanhos de disco de armazenamento premium
O armazenamento Premium oferece vários tamanhos para que possa escolher o que melhor se adapta às suas necessidades. Cada tamanho de disco tem um limite de escala diferente para IOPS, largura de banda e armazenamento. Escolha o tamanho certo do disco de armazenamento premium dependendo dos requisitos do aplicativo e do tamanho da VM de alta escala. A tabela a seguir mostra os tamanhos dos discos e seus recursos. Atualmente, os tamanhos P4, P6, P15, P60, P70 e P80 são suportados apenas para discos gerenciados.
| Tamanhos 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 | 2048 | 4,096 | 8,192 | 16,384 | 32 767 |
| IOPS provisionadas de base por disco | 120 | 120 | 120 | 120 | 240 | 500 | 1100 | 2300 | 5.000 | 7500 | 7500 | 16 000 | 18 000 | 20.000 |
| **IOPS provisionadas expandidas por disco | N/A | N/D | N/D | N/D | N/D | N/D | N/D | N/A | 8,000 | 16 000 | 20.000 | 20.000 | 20.000 | 20.000 |
| Taxa de transferência provisionada de 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/A | N/D | N/D | N/D | N/D | N/D | N/D | N/A | 300 MB/s | 600 MB/s | 900 MB/s | 900 MB/s | 900 MB/s | 900 MB/s |
| IOPS de intermitência máxima por disco | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* |
| Taxa de transferência máxima de burst 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 do burst | 30 minutos | 30 minutos | 30 minutos | 30 minutos | 30 minutos | 30 minutos | 30 minutos | 30 minutos | Ilimitado* | Ilimitado* | Ilimitado* | Ilimitado* | Ilimitado* | Ilimitado* |
| Elegível para reserva | No | 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 apenas a discos com bursting a pedido ativado.
** Aplica-se apenas a discos com desempenho mais (pré-visualização) ativado.
O número de discos escolhido depende do tamanho do disco escolhido. Você pode usar um único disco P50 ou vários discos P10 para atender aos requisitos do seu aplicativo. Leve em consideração as considerações listadas aqui ao fazer a 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 IOPS total e a taxa de transferência dos discos estão dentro dos limites de escala do tamanho da VM escolhido.
Por exemplo, se um requisito de aplicativo for uma taxa de transferência máxima de 250 MB/seg e você estiver usando uma VM DS4 com um único disco P30, a VM DS4 poderá fornecer até 256 MB/seg de taxa de transferência. No entanto, um único disco P30 tem um limite de taxa de transferência de 200 MB/seg. Assim, o aplicativo é restrito em 200 MB / seg por causa do limite de disco. Para superar esse limite, provisione mais de um disco de dados para a VM ou redimensione seus discos para P40 ou P50.
Nota
As leituras servidas pelo cache não estão incluídas no IOPS e na taxa de transferência do disco, portanto, não estão sujeitas a limites de disco. O cache tem seu limite de IOPS e taxa de transferência separados por VM.
Por exemplo, inicialmente suas leituras e gravações são de 60 MB/seg e 40 MB/seg, respectivamente. Com o tempo, o cache aquece e serve cada vez mais leituras do cache. Em seguida, 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 necessários avaliando os requisitos do aplicativo. Cada tamanho de VM também tem um limite no número de discos que você pode anexar à VM. Normalmente, essa quantidade é o dobro do número de núcleos. Certifique-se de que o tamanho da VM escolhido possa suportar o número de discos necessários.
Lembre-se de que os discos de armazenamento premium têm recursos de desempenho mais altos em comparação com os discos de armazenamento padrão. Se você estiver migrando seu aplicativo de uma VM IaaS do Azure usando armazenamento padrão para armazenamento premium, provavelmente precisará de menos discos premium para obter o mesmo ou maior desempenho para seu aplicativo.
Colocação em cache do disco
As VMs de alta escala que usam armazenamento premium têm uma tecnologia de cache de várias camadas chamada BlobCache. O BlobCache usa uma combinação da RAM do host e SSD local para cache. Esse cache está disponível para os discos persistentes de armazenamento premium e os discos locais da VM. Por padrão, essa configuração de cache é definida como ReadWrite para discos do sistema operacional e ReadOnly para discos de dados hospedados no armazenamento premium. Com o cache de disco habilitado nos discos de 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 é suportado para discos de 4 TiB ou maiores. Se vários discos estiverem conectados à sua VM, cada disco menor que 4 TiB oferece suporte a cache.
Alterar a definição de cache de um disco do Azure desanexa e anexa novamente o disco de destino. Caso se trate do disco do sistema operativo, a VM é reiniciada. Pare todos os aplicativos e serviços que possam ser afetados por essa interrupção antes de alterar a configuração do cache de disco. Não seguir essas recomendações pode levar à corrupção de dados.
Para saber mais sobre como o BlobCache funciona, consulte a postagem do blog Por dentro do 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 de carga de trabalho que o disco está manipulando. A tabela a seguir mostra as configurações de cache padrão para SO e discos de dados.
| Tipo de disco | Configuração de cache padrão |
|---|---|
| Disco do SO | ReadWrite |
| Disco de dados | ReadOnly |
Recomendamos as seguintes configurações de cache de disco para discos de dados.
| Configuração de cache de disco | Recomendação para quando usar essa configuração |
|---|---|
| Nenhuma | Configure o cache do host como Nenhum para discos somente gravação e discos pesados de gravação. |
| ReadOnly | Configure o cache do host como Somente leitura para discos somente leitura e leitura-gravação. |
| ReadWrite | Configure o cache do host como ReadWrite somente se seu aplicativo manipular corretamente a gravação de dados armazenados em cache em discos persistentes quando necessário. |
ReadOnly
Ao configurar o cache ReadOnly em discos de dados de armazenamento premium, você pode obter baixa latência de leitura e obter IOPS de leitura e taxa de transferência muito altas para seu aplicativo por dois motivos:
- As leituras realizadas a partir do cache, que está na memória da VM e no SSD local, são mais rápidas do que as leituras do disco de dados, que está no Armazenamento de Blobs do Azure.
- O armazenamento premium não conta as leituras servidas do cache para o IOPS e a taxa de transferência do disco. Por esse motivo, seu aplicativo pode obter IOPS e taxa de transferência totais mais altas.
ReadWrite
Por padrão, os discos do sistema operacional têm o cache ReadWrite habilitado. Recentemente, também adicionamos suporte para cache ReadWrite em discos de dados. Se você estiver usando o cache ReadWrite , deverá ter uma maneira adequada de gravar os dados do cache em discos persistentes. Por exemplo, o SQL Server lida sozinho com a gravação de dados armazenados em cache nos discos de armazenamento persistentes. Usar o cache ReadWrite com um aplicativo que não lida com a persistência dos dados necessários pode levar à perda de dados, se a VM falhar.
Nenhuma
Atualmente, Nenhum só é suportado em discos de dados. Não é suportado em discos de SO. Se você definir Nenhum em um disco do sistema operacional, ele substituirá essa configuração internamente e a definirá como Somente leitura.
Como exemplo, você pode aplicar essas diretrizes ao SQL Server em execução no armazenamento premium seguindo estas etapas:
- Configure o cache ReadOnly em discos de armazenamento premium que hospedam arquivos de dados.
- As leituras rápidas do cache diminuem o tempo de consulta do SQL Server porque as páginas de dados são recuperadas mais rapidamente do cache em comparação com diretamente dos discos de dados.
- Servir leituras de cache significa que há mais taxa de transferência disponível a partir de 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 reconstruções de índice.
- Configure o cache Nenhum em discos de armazenamento premium que hospedam os arquivos de log.
- Os arquivos de log têm principalmente operações pesadas de gravação, portanto, eles não se beneficiam do cache ReadOnly .
Otimize o desempenho em VMs Linux
Para todos os SSDs Premium ou Ultra Disks, você poderá desativar barreiras para sistemas de arquivos no disco para melhorar o desempenho quando se sabe que não há caches que possam perder dados. Se o cache de disco do Azure estiver definido como Somente leitura ou Nenhum, você poderá desabilitar barreiras. Mas se o cache estiver definido como ReadWrite, as barreiras devem permanecer habilitadas para garantir a durabilidade da gravação. As barreiras normalmente são habilitadas por padrão, mas você pode desabilitar barreiras usando um dos seguintes métodos, dependendo do tipo de sistema de arquivos:
- reiserFS: Use a opção de montagem barrier=none para desativar barreiras. Para habilitar explicitamente as barreiras, use barrier=flush.
- ext3/ext4: Use a opção de montagem barrier=0 para desativar barreiras. Para habilitar explicitamente barreiras, use barrier=1.
- XFS: Use a opção de montagem sem barreira para desativar barreiras. Para habilitar explicitamente barreiras, use barreira. A partir da versão 4.10 do kernel Linux principal, o design do sistema de arquivos XFS sempre garante durabilidade. A desativação de barreiras não tem efeito e a opção sem barreira é preterida. No entanto, algumas distribuições Linux podem ter retroportado as alterações para uma versão de distribuição com uma versão anterior do kernel. Verifique com o seu fornecedor de distribuição o status na distribuição e na versão que você está executando.
Distribuição de disco
Quando uma VM de alta escala é conectada a vários discos persistentes de armazenamento premium, os discos podem ser distribuídos juntos para agregar suas IOPs, largura de banda e capacidade de armazenamento.
No Windows, você pode usar Espaços de Armazenamento para distribuir discos juntos. Você deve configurar uma coluna para cada disco em um pool. Caso contrário, o desempenho geral do volume distribuído pode ser menor do que o esperado devido à distribuição desigual do tráfego entre os discos.
Usando a interface do usuário do Gerenciador do Servidor, você pode definir o número total de colunas até 8 um volume distribuído. Quando você estiver anexando mais de oito discos, use o PowerShell para criar o volume. Usando o PowerShell, você pode definir o número de colunas igual ao número de discos. Por exemplo, se houver 16 discos em um único conjunto de faixas, especifique 16 colunas NumberOfColumns no parâmetro do cmdlet PowerShell New-VirtualDisk .
No Linux, use o utilitário MDADM para distribuir discos juntos. Para obter etapas sobre como distribuir discos no Linux, consulte Configurar RAID de software no Linux.
Tamanho da risca
Uma configuração importante no striping de disco é o tamanho do stripe. O tamanho da faixa ou tamanho do bloco é o menor bloco de dados que um aplicativo pode endereçar em um volume distribuído. O tamanho da faixa que você configura depende do tipo de aplicativo e seu padrão de solicitação. Se você escolher o tamanho de faixa errado, isso pode levar a um desalinhamento de E/S, o que leva a um desempenho degradado do seu aplicativo.
Por exemplo, se uma solicitação de E/S gerada pelo seu aplicativo for maior do que o tamanho da distribuição de disco, o sistema de armazenamento a gravará através dos limites da unidade de distribuição em mais de um disco. Quando é hora de acessar esses dados, ele tem que procurar em mais de uma unidade de faixa para concluir a solicitação. O efeito cumulativo de tal comportamento pode levar a uma degradação substancial do desempenho. Por outro lado, se o tamanho da solicitação de E/S for menor do que o tamanho da faixa e se for aleatório por natureza, as solicitações de E/S poderão se somar no mesmo disco, causando um afunilamento e, por fim, degradando o desempenho de E/S.
Dependendo do tipo de carga de trabalho que seu aplicativo está executando, escolha um tamanho de faixa apropriado. Para solicitações aleatórias de E/S pequenas, use um tamanho de faixa menor. Para solicitações de E/S sequenciais grandes, use um tamanho de faixa maior. Descubra as recomendações de tamanho de faixa 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 256 KB para cargas de trabalho de data warehouse. Para obter mais informações, consulte Práticas recomendadas de desempenho para o SQL Server em VMs do Azure.
Nota
Você pode distribuir um máximo de 32 discos de armazenamento premium em uma VM da série DS e 64 discos de armazenamento premium em uma VM da série GS.
Multithreading
O Azure projetou a plataforma de armazenamento premium para ser massivamente paralela. Por esse motivo, um aplicativo multithreaded alcança um desempenho mais alto do que um aplicativo single-threaded. Um aplicativo multithreaded divide suas tarefas em vários threads e aumenta a eficiência de sua execução utilizando ao máximo os recursos da VM e do disco.
Por exemplo, se seu aplicativo estiver sendo executado em uma única VM de 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 de E/S em um disco, a CPU pode alternar para o outro thread. Desta forma, dois threads podem realizar mais do que um único thread faria. Se a VM tiver mais de um núcleo, ela diminui ainda mais o tempo de execução porque cada núcleo pode executar tarefas em paralelo.
Talvez não seja possível alterar a maneira como um aplicativo pronto para uso implementa threading único ou multithreading. Por exemplo, o SQL Server é capaz de lidar com várias CPUs e vários núcleos. No entanto, o SQL Server decide em que condições ele usa um ou mais threads para processar uma consulta. Ele pode executar consultas e criar índices usando multithreading. Para uma consulta que envolve unir tabelas grandes e classificar dados antes de retornar ao usuário, o SQL Server provavelmente usa vários threads. Um usuário não pode controlar se o SQL Server executa uma consulta usando um único thread ou vários threads.
Há definições de configuração que você pode alterar para influenciar o multithreading ou o processamento paralelo de um aplicativo. Por exemplo, para o SQL Server é a max degree of parallelism configuração. Essa configuração, chamada MAXDOP, permite configurar o número máximo de processadores que o SQL Server pode usar durante o processamento paralelo. Você pode configurar o MAXDOP para consultas individuais ou operações de índice. Esse recurso é benéfico quando você deseja equilibrar os recursos do seu sistema para um aplicativo crítico de desempenho.
Por exemplo, digamos que seu aplicativo que está usando o SQL Server esteja executando uma consulta grande e uma operação de índice ao mesmo tempo. Vamos supor que você queria que a operação de índice tivesse mais desempenho em comparação com a consulta grande. Nesse caso, você pode definir o valor MAXDOP da operação de índice para ser maior do que o valor MAXDOP para a consulta. Dessa forma, o SQL Server tem mais processadores do que pode usar para a operação de índice em comparação com o número de processadores que pode dedicar à consulta grande. Lembre-se, você não controla o número de threads que o SQL Server usa para cada operação. Você pode controlar o número máximo de processadores dedicados para multithreading.
Saiba mais sobre os graus de paralelismo no SQL Server. Descubra como essas configurações influenciam o multithreading em seu aplicativo e suas configurações para otimizar o desempenho.
Profundidade da fila
A profundidade da fila ou o comprimento da fila ou o 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 seu aplicativo pode alinhar, que os discos de armazenamento processam. Isso afeta todos os três indicadores de desempenho do aplicativo discutidos 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 alcançado pelo aplicativo. Se a profundidade da fila for grande, o aplicativo poderá executar mais operações simultaneamente, ou seja, mais multithreading. Se a profundidade da fila for pequena, mesmo que o aplicativo seja multithreaded, 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, porque se ela for definida incorretamente, fará mais mal do que bem. Os aplicativos definem o valor certo da profundidade da fila para obter o desempenho ideal. É importante entender esse conceito para que você possa solucionar problemas de desempenho com seu aplicativo. Você também pode observar os efeitos da profundidade da fila executando ferramentas de benchmarking em seu sistema.
Alguns aplicativos fornecem configurações para influenciar a profundidade da fila. Por exemplo, a configuração MAXDOP no SQL Server explicada na seção anterior. MAXDOP é uma maneira de influenciar a profundidade da fila e o multithreading, embora não altere diretamente o valor da profundidade da fila do SQL Server.
Alta profundidade da fila
Uma alta profundidade de fila alinha mais operações no disco. O disco conhece a próxima solicitação em sua fila com antecedência. Assim, o disco pode programar operações com antecedência e processá-las em uma sequência ideal. Como o aplicativo está enviando mais solicitações para o disco, o disco pode processar mais E/S paralelas. Em última análise, o aplicativo pode alcançar IOPS mais altas. Como o aplicativo está processando mais solicitações, a taxa de transferência total do aplicativo também aumenta.
Normalmente, um aplicativo pode atingir a taxa de transferência máxima com 8 a 16+ E/S pendentes por disco conectado. Se a profundidade de uma fila for uma, o aplicativo não está enviando E/S suficientes para o sistema e processa uma quantidade menor em um determinado período. Em outras palavras, menos rendimento.
Por exemplo, no SQL Server, definir o valor MAXDOP para uma consulta informa ao 4 SQL Server que ele pode usar até quatro núcleos para executar a consulta. O SQL Server determina o melhor valor de profundidade de fila e o número de núcleos para a execução da consulta.
Profundidade de fila ideal
Um valor de profundidade de fila muito alto também tem suas desvantagens. Se o valor de profundidade da fila for muito alto, o aplicativo tentará gerar IOPS muito altas. A menos que o aplicativo tenha discos persistentes com IOPS provisionadas suficientes, 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 qualquer valor alto, mas para um valor ideal, que pode fornecer IOPS suficientes para o aplicativo sem afetar as latências. Por exemplo, se a latência do aplicativo precisar ser de 1 milissegundo, a profundidade da fila necessária para atingir 5.000 IOPS será QD = 5.000 x 0,001 = 5.
Profundidade da fila para volume distribuído
Para um volume distribuído, mantenha uma profundidade de fila alta o suficiente para que cada disco tenha uma profundidade de fila de pico individualmente. Por exemplo, considere um aplicativo que empurra uma profundidade de fila de 2 e há quatro discos na distribuição. As duas solicitações de E/S vão para dois discos e os dois discos restantes estão ociosos. Portanto, configure a profundidade da fila para que todos os discos possam estar 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 seu aplicativo tenta direcionar IOPS ou taxa de transferência acima desses limites do que a VM ou o disco podem lidar, o armazenamento premium o limita. O resultado é um desempenho degradado em seu aplicativo, o que pode significar maior latência, menor taxa de transferência ou IOPS mais baixa.
Se o armazenamento premium não for acelerado, seu aplicativo poderá falhar completamente ao exceder o que seus recursos são capazes de alcançar. Para evitar problemas de desempenho devido à limitação, sempre provisione recursos suficientes para seu aplicativo. Leve em consideração o que discutimos nas seções anteriores de tamanhos de VM e tamanhos de disco. O benchmarking é a melhor maneira de descobrir quais recursos você precisa para hospedar seu aplicativo.
Próximos passos
Se você estiver procurando fazer benchmarking do seu disco, consulte os seguintes artigos:
- Para Linux: faça benchmark do seu aplicativo no Armazenamento em Disco do Azure
- Para Windows: Avaliar comparativamente um disco
Saiba mais sobre os tipos de disco disponíveis:
- Para Linux: Selecione um tipo de disco
- Para Windows: Selecione um tipo de disco
Para usuários do SQL Server, consulte os artigos sobre práticas recomendadas de desempenho para o SQL Server: