Compartilhar via

Diagnóstico de solução de problemas de desempenho de hiperescala do SQL

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Para solucionar problemas de desempenho em um banco de dados de Hiperescala, as metodologias gerais de ajuste de desempenho de SQL são o ponto de partida de qualquer investigação de desempenho. No entanto, dada a arquitetura distribuída do Hyperscale, talvez seja necessário considerar dados adicionais de diagnóstico. Este artigo descreve dados de diagnóstico específicos de hiperescala.

Redução das esperas de taxa de logs

Cada banco de dados e pool elástico no Banco de Dados SQL do Azure gerencia a taxa de geração de logs por meio de governança de taxa de logs. Na Hiperescala, o limite de governança da taxa de log é definido como 105 MB/s, independentemente da capacidade de computação. Esse valor é exposto na coluna primary_max_log_rate em sys.dm_user_db_resource_governance.

Em algumas ocasiões, a taxa de geração de log na réplica de computação primária deve ser reduzida para manter os SLAs de recuperabilidade. Por exemplo, isso pode acontecer quando um servidor de página ou outra réplica de computação está significativamente atrasado na aplicação de novos registros de log do serviço de logs. Se nenhum componente de Hiperescala estiver atrasado, o mecanismo de governança da taxa de logs permitirá que a taxa de geração de logs atinja 100 MB/s. Essa é a taxa máxima efetiva de geração de log em todos os tamanhos de computação Hyperscale.

Observação

A taxa de geração de log de 150 MB/s está disponível como um recurso de versão prévia de aceitação. Para obter mais informações e optar por 150 MB/s, veja Blog: Melhorias em hiperescala de novembro de 2024.

Os seguintes tipos de espera aparecem em sys.dm_os_wait_stats quando a taxa de logs é reduzida:

Tipo de espera Razão
RBIO_RG_STORAGE Consumo de log atrasado por um servidor de página
RBIO_RG_DESTAGE Consumo de logs atrasado devido ao armazenamento de log de longo prazo
RBIO_RG_REPLICA Consumo de logs atrasado por uma réplica secundária de HA ou uma réplica nomeada
RBIO_RG_GEOREPLICA Consumo de logs atrasado por uma réplica geográfica secundária
RBIO_RG_DESTAGE Consumo de logs atrasado pelo serviço de logs
RBIO_RG_LOCALDESTAGE Consumo de logs atrasado pelo serviço de logs
RBIO_RG_STORAGE_CHECKPOINT Consumo de logs atrasado por um servidor de páginas devido à lentidão de um ponto de verificação do banco de dados
RBIO_RG_MIGRATION_TARGET Atraso no consumo de log pelo banco de dados não hiperescala durante a migração reversa

A DMF (função de gerenciamento dinâmico) sys.dm_hs_database_log_rate() fornece detalhes adicionais para ajudar você a entender a redução da taxa de logs, se houver. Por exemplo, ela pode informar qual réplica secundária específica está atrasada na aplicação de registros de log e o tamanho total do log de transações que ainda não foi aplicado.

Leituras de servidor de página

As réplicas de computação não armazenam em cache uma cópia completa do banco de dados localmente. Os dados locais para a réplica de computação são armazenados no pool de buffers (na memória) e no cache da RBPEX (extensão de pool de buffers resiliente) local que contém um subconjunto das páginas de dados acessadas com mais frequência. Esse cache SSD local é dimensionado proporcionalmente ao tamanho da computação. Cada servidor de página, por outro lado, tem um cache SSD completo para a parte do banco de dados que ele mantém.

Quando uma ES de leitura é emitida em uma réplica de computação, se os dados não existirem no pool de buffers ou no cache SSD local, a página no LSN (Número de Sequência de Log) solicitado será buscada do servidor de página correspondente. As leituras dos servidores de página são remotas e são mais lentas do que as leituras do cache SSD local. Ao solucionar problemas de desempenho relacionados a E/S, precisamos saber quantas E/S foram feitas por meio de leituras de servidor de página relativamente mais lentas.

Várias DMVs (exibições de gerenciamento dinâmico) e eventos estendidos têm colunas e campos que especificam o número de leituras remotas de um servidor de páginas, que podem ser comparadas com o total de leituras. O Repositório de Consultas também captura leituras de páginas no servidor nas estatísticas de runtime de consulta.

  • Colunas para relatar as leituras do servidor da página estão disponíveis em DMVs de execução e exibições de catálogo:
  • Os campos de leitura do servidor de página estão presentes nos seguintes eventos estendidos:
    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info
  • ActualPageServerReads/ActualPageServerReadAheads atributos estão presentes no XML do plano de consulta para planos que incluem estatísticas de tempo de execução. Por exemplo: 
    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Dica

    Para exibir esses atributos na janela de propriedades do plano de consulta, é necessário o SSMS (SQL Server Management Studio) 18.3 ou posterior.

Estatísticas de arquivo virtual e contabilização de E/S

No Banco de Dados SQL do Azure, o sys.dm_io_virtual_file_stats() DMF é uma maneira de monitorar estatísticas de E/S do banco de dados, como IOPS, taxa de transferência e latência. As características de E/S na Hiperescala são diferentes devido à arquitetura distribuída . Nesta seção, nos concentramos na leitura e gravação de E/S, conforme visto nesta DMF. Na Hiperescala, cada arquivo de dados visível neste DMF corresponde a um servidor de página. O DMF também fornece estatísticas de E/S para o cache SSD local na réplica de computação e para o log de transações.

Uso do cache SSD local

Como o cache SSD local existe na mesma réplica de computação em que o mecanismo de banco de dados está processando consultas, as operações de E/S nesse cache são mais rápidas do que E/S em servidores de página. Em um banco de dados hiperescala ou pool elástico, sys.dm_io_virtual_file_stats() tem uma linha especial relatando estatísticas de E/S para o cache SSD local. Essa linha tem o valor de 0 para colunas database_id e file_id. Por exemplo, a consulta abaixo retorna as estatísticas de E/S do cache SSD local desde a inicialização do banco de dados.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Uma proporção de leituras do cache SSD local em relação às leituras agregadas de todos os outros arquivos de dados é a taxa de acertos do cache SSD local. Essa métrica é fornecida pelos contadores de desempenho RBPEX cache hit ratio e RBPEX cache hit ratio base, disponíveis na DMV sys.dm_os_performance_counters.

Leituras de dados

  • Quando as leituras são emitidas pelo mecanismo de banco de dados em uma réplica de computação, elas podem ser atendidas pelo cache SSD local, por servidores de páginas ou por uma combinação dos dois, caso estejam lendo várias páginas.
  • Quando a réplica de computação lê algumas páginas de um arquivo de dados específico, por exemplo, o arquivo com file_id 1, se esses dados estão apenas no cache local de SSD, toda a E/S dessa leitura é contabilizada contra file_id 0. Se alguma parte desses dados estiver no cache SSD local e alguma parte estiver em servidores de página, a ES será contabilizada para file_id 0 para a parte proveniente do cache SSD local, enquanto a parte proveniente dos servidores de página será contabilizada para seus arquivos correspondentes.
  • Quando uma réplica de computação solicita uma página em um LSN específico de um servidor de página, se o servidor de página ainda não tiver acessado o LSN solicitado, a leitura na réplica de computação aguardará a atualização do servidor de páginas antes de retornar a página. Para qualquer leitura de um servidor de página na réplica de computação, você verá um tipo de espera PAGEIOLATCH_* se ele estiver esperando essa ES. Em hiperescala, esse tempo de espera inclui o tempo para acompanhar a página solicitada no servidor de página para o LSN necessário e o tempo necessário para transferir a página do servidor de página para a réplica de computação.
  • Leituras grandes, como read-ahead, geralmente são feitas usando leituras de scatter-gather. Isso permite ler até 4 MB como uma só operação de ES de leitura. No entanto, quando os dados que estão sendo lidos estão no cache SSD local, essas leituras são contabilizados como várias leituras individuais de 8 KB, já que o pool de buffers e o cache SSD local sempre usam páginas de 8 KB. Como resultado, o número de ESs de leitura vistos no cache SSD local pode ser maior do que o número real de ESs executadas pelo mecanismo.

Gravações de dados

  • A réplica de computação primária não grava diretamente em servidores de página. Em vez disso, os registros de log do serviço de log são reproduzidos nos servidores de página correspondentes.
  • As gravações na réplica de computação são feitas predominantemente no cache SSD local (file_id 0). Para gravações maiores que 8 KB, ou seja, aquelas realizadas usando a operação de escrita por coleta, cada operação de gravação é dividida em várias escritas individuais de 8 KB no cache SSD local, uma vez que tanto o pool de buffers quanto o cache SSD local sempre utilizam páginas de 8 KB. Como resultado, o número de ESs de gravação vistos no cache SSD local pode ser maior do que o número real de ESs executadas pelo mecanismo.
  • Arquivos de dados diferentes de file_id 0 que correspondem aos servidores de página também podem mostrar gravações. Na Hiperescala, essas gravações são simuladas, pois as réplicas de computação nunca gravam diretamente em servidores de páginas. As estatísticas de E/S são contabilizadas conforme ocorrem na réplica de computação. IOPS, taxa de transferência e latência observadas em uma réplica de computação para arquivos de dados diferentes de file_id 0 não correspondem às estatísticas reais de E/S das gravações que ocorrem em servidores de página.

Gravações de log

  • Na réplica de computação primária, uma gravação de log é contabilizada em sys.dm_io_virtual_file_stats() sob file_id 2.
  • Ao contrário dos Grupos de Disponibilidade AlwaysOn, quando uma transação é confirmada na réplica de computação primária, os registros de log não são consolidados na réplica secundária. Na Hiperescala, o log é consolidado no serviço de log e aplicado às réplicas secundárias de maneira assíncrona. Como as gravações de log não ocorrem de fato em réplicas secundárias, qualquer contabilização de E/S de log em sys.dm_io_virtual_file_stats() nas réplicas secundárias não deve ser usada como estatísticas de E/S do log de transações.

E/S de dados nas estatísticas de utilização de recursos

Em um banco de dados que não é de hiperescala, os IOPS de leitura e gravação combinados em relação aos arquivos de dado, referentes ao limite de IOPS de dados de governança de recursos, são relatados nas exibições sys.dm_db_resource_stats e sys.resource_stats na coluna avg_data_io_percent. As DMVs correspondentes para pools elásticos são sys.dm_elastic_pool_resource_stats e sys.elastic_pool_resource_stats. Os mesmos valores são informados como as métricas do Azure Monitor de Percentagem de ES de Dados para bancos de dados e pools elásticos.

Em um banco de dados de hiperescala, essas colunas e métricas mostram a utilização de IOPS dos dados em relação ao limite para armazenamento em SSD local apenas na réplica de computação, que inclui E/S no cache SSD local e no banco de dados tempdb. Um valor de 100% nessa coluna indica que a governança de recursos está limitando o IOPS de armazenamento local. Se isso estiver correlacionado a um problema de desempenho, ajuste a carga de trabalho para gerar menos ES ou aumente o tamanho da computação para aumentar o limitemáximo de IOPS de Dados da governança de recursos. Para a governança de recursos das leituras e gravações do cache SSD local, o sistema conta ESs individuais de 8 KB, em vez de ESs maiores que podem ser emitidas pelo mecanismo de banco de dados.

A ES de dados em servidores de página não aparece nas visões de utilização de recursos ou nas métricas do Azure Monitor, mas é relatada em sys.dm_io_virtual_file_stats() conforme já descrito.

Conteúdo relacionado