Coleta de linha de base: melhores práticas de desempenho do SQL Server na VM do Azure

Artigo
04/26/2023

Aplica-se a:SQL Server na VM do Azure

Este artigo fornece as informações de coleta de linha de base como uma série de melhores práticas e diretrizes para otimizar o desempenho do SQL Server em VMs (Máquinas Virtuais) do Azure.

Normalmente, há uma compensação entre a otimização para custos e a otimização para desempenho. Esta série de melhores práticas de desempenho tem como foco obter o melhor desempenho do SQL Server em Máquinas Virtuais do Azure. Se a sua carga de trabalho tem menos demanda, talvez você não precise realizar todas as otimizações recomendadas. Considere suas necessidades de desempenho, custos e padrões de carga de trabalho ao avaliar essas recomendações.

Visão geral

Para obter uma abordagem prescritiva, reúna contadores de desempenho usando PerfMon/LogMan e capture estatísticas de espera do SQL Server para entender melhor as pressões gerais e os potenciais gargalos do ambiente de origem.

Comece coletando a CPU, a memória, a IOPS, a taxa de transferência e a latência da carga de trabalho de origem em horários de pico conforme a lista de verificação de desempenho do aplicativo.

Reúna os dados durante os horários de pico, como as cargas de trabalho de um dia útil normal, mas também de outros processos de carga alta, como processamento de fim de dia e cargas de trabalho de ETL de fim de semana. Considere a possibilidade de escalar verticalmente os recursos para cargas de trabalho mais pesadas que o normal, como o processamento de fim de trimestre, e reduzi-los verticalmente após a conclusão da carga de trabalho.

Use a análise de desempenho para selecionar o tamanho da VM que pode ser escalado de acordo com os requisitos de desempenho da carga de trabalho.

Armazenamento

O desempenho do SQL Server depende grandemente do subsistema de entrada/saída e o desempenho do armazenamento é medido pela IOPS e pela taxa de transferência. A menos que o banco de dados caiba na memória física, o SQL Server constantemente leva as páginas do banco de dados para dentro e para fora do pool de buffers. Os arquivos de dados para SQL Server devem ser tratados de outra forma. O acesso a arquivos de log é sequencial, exceto quando uma transação precisa ser revertida onde os arquivos de dados, incluindo tempdb, são acessados aleatoriamente. Se você tem um subsistema de entrada/saída lento, os usuários podem enfrentar problemas de desempenho, como tempos de resposta lentos e tarefas que não são concluídas devido a tempos limite.

As máquinas virtuais do Azure Marketplace têm os arquivos de log em um disco físico separado dos arquivos de dados por padrão. A contagem e o tamanho dos arquivos de dados de tempdb atendem às melhores práticas e são direcionados para a unidade efêmera D:\.

Os seguintes contadores PerfMon ajudam a validar a taxa de transferência de entrada/saída exigida pelo SQL Server:

\Disco Lógico\Leituras de Disco/S (IOPS de leitura)
\Disco Lógico\Gravações de Disco/S (IOPS de gravação)
\Disco Lógico\Bytes de Leitura de Disco/S (requisitos de taxa de transferência de leitura para os arquivos de dados, log e tempdb)
\Disco Lógico\Bytes de Gravação de Disco/S (requisitos de taxa de transferência de gravação para os arquivos de dados, log e tempdb)

Usando os requisitos de IOPS e de taxa de transferência em níveis de pico, avalie os tamanhos de VM que correspondem à capacidade das suas medições.

Por exemplo, se a carga de trabalho exigir 20 mil IOPS de leitura e 10 mil IOPS de gravação, você poderá escolher entre E16s_v3 (com até 32 mil IOPS armazenadas em cache e 25.600 não armazenadas em cache) ou M16_s (com até 20 mil IOPS armazenadas em cache e 10 mil não armazenadas em cache) com dois discos P30 divididos em faixas usando os Espaços de Armazenamento.

Certifique-se de que você compreendeu os requisitos de taxa de transferência e de IOPS da carga de trabalho, pois as VMs têm limites de escala diferentes para ambos.

Memória

Acompanhe a memória externa usada pelo sistema operacional e a memória usada internamente pelo SQL Server. A identificação da pressão para os dois componentes vai ajudar a dimensionar as máquinas virtuais e a identificar as oportunidades de ajuste.

Os seguintes contadores PerfMon ajudam a validar a integridade da memória da máquina virtual do SQL Server:

Computação

A computação no Azure é gerenciada de maneira diferente da local. Os servidores locais são criados para durar vários anos sem atualização devido à sobrecarga de gerenciamento e ao custo de aquisição de um novo hardware. A virtualização atenua alguns desses problemas, mas os aplicativos são otimizados para aproveitar ao máximo o hardware subjacente, o que significa que qualquer alteração significativa no consumo de recursos requer a redistribuição de todo o ambiente físico.

Isso não é um problema no Azure, em que é fácil de conseguir uma nova máquina virtual em uma série diferente de hardware ou mesmo em uma região diferente.

Para aproveitar ao máximo os recursos de máquinas virtuais no Azure, as máquinas virtuais do Azure devem ser configuradas para manter a média de CPU máxima, sem afetar a carga de trabalho.

Os seguintes contadores PerfMon ajudam a validar a integridade da computação da máquina virtual do SQL Server:

\Processor Information(_Total)% Tempo do processador
\Processo(sqlservr)% Tempo do Processador

Observação

Tente direcionar o uso de 80% de sua computação, com picos acima de 90%, mas sem alcançar 100% por um período prolongado. Basicamente, você deve provisionar a computação de que o aplicativo precisa e planejar para escalar ou reduzir verticalmente conforme a necessidade da empresa.

Próximas etapas

Para saber mais, confira os outros artigos desta série de melhores práticas:

Para obter as melhores práticas de segurança, confira Considerações sobre segurança para o SQL Server em Máquinas Virtuais do Azure.

Revise outros artigos sobre Máquinas Virtuais do SQL Server em Visão geral do SQL Server nas Máquinas Virtuais do Azure. Em caso de dúvidas sobre máquinas virtuais do SQL Server, consulte as Perguntas frequentes.