Partilhar via

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

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Para solucionar problemas de desempenho em um banco de dados Hyperscale, as metodologias gerais de ajuste de desempenho no nó de computação do Banco de Dados SQL do Azure são o ponto de partida de uma investigação de desempenho. No entanto, dada a arquitetura distribuída do Hyperscale, diagnósticos adicionais foram adicionados para ajudar. Este artigo descreve dados de diagnóstico específicos da hiperescala.

Espera de limitação da taxa de registro

Cada objetivo de serviço do Banco de Dados SQL do Azure tem limites de taxa de geração de log impostos por meio da governança de taxa de log. No Hyperscale, o limite de governança de log é definido como 105 MB/seg, independentemente do nível de serviço. Esse valor é exposto na primary_max_log_rate coluna em sys.dm_user_db_resource_governance.

No entanto, há momentos em que a taxa de geração de log na réplica de computação primária precisa ser limitada para manter os SLAs de capacidade de recuperação. Essa limitação acontece 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 log. Se nenhum servidor de página ou réplica estiver atrasado, o mecanismo de limitação permitirá que a taxa de geração de logs atinja 100 MB/s. Esta é a taxa máxima efetiva de geração de logs em todos os objetivos do serviço Hyperscale.

Os seguintes tipos de espera (em sys.dm_os_wait_stats) descrevem os motivos pelos quais a taxa de log pode ser limitada na réplica de computação primária:

Tipo de espera Description
RBIO_RG_STORAGE Ocorre quando uma taxa de geração de log do nó de computação primário do banco de dados Hyperscale está sendo limitada devido ao consumo de log atrasado no(s) servidor(es) de página.
RBIO_RG_DESTAGE Ocorre quando uma taxa de geração de log de nó de computação de banco de dados Hyperscale está sendo limitada devido ao consumo de log atrasado pelo armazenamento de log de longo prazo.
RBIO_RG_REPLICA Ocorre quando uma taxa de geração de log de nó de computação de banco de dados Hyperscale está sendo limitada devido ao consumo de log atrasado pela(s) réplica(s) secundária(s) legível(is).
RBIO_RG_GEOREPLICA Ocorre quando uma taxa de geração de log de nó de computação de banco de dados Hyperscale está sendo limitada devido ao consumo de log atrasado pela réplica secundária geográfica.
RBIO_RG_LOCALDESTAGE Ocorre quando uma taxa de geração de log de nó de computação de banco de dados Hyperscale está sendo limitada devido ao consumo de log atrasado pelo serviço de log.

O servidor de páginas lê

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 RBPEX (extensão do pool de buffer resiliente local) que é um cache parcial (sem cobertura) de páginas de dados. Esse cache RBPEX local é dimensionado proporcionalmente ao tamanho da computação e é três vezes a memória da camada de computação. O RBPEX é semelhante ao buffer pool por ter os dados acessados com mais frequência. Cada servidor de página, por outro lado, tem um cache RBPEX de cobertura para a parte do banco de dados que mantém.

Quando uma leitura é emitida em uma réplica de computação, se os dados não existirem no pool de buffers ou no cache RBPEX local, uma chamada de função getPage(pageId, LSN) será emitida e a página será buscada no servidor de página correspondente. As leituras dos servidores de página são leituras remotas e, portanto, são mais lentas do que as leituras do RBPEX local. Ao solucionar problemas de desempenho relacionados a E/S, precisamos ser capazes de saber quantas E/S foram feitas por meio de leituras de servidor de página remoto relativamente mais lentas.

Várias exibições gerenciadas dinâmicas (DMVs) e eventos estendidos têm colunas e campos que especificam o número de leituras remotas de um servidor de página, que podem ser comparadas com o total de leituras. O repositório de consultas também captura leituras remotas como parte das estatísticas de tempo de execução da consulta.

  • As colunas para leituras do servidor de página de relatório estão disponíveis em DMVs de execução e exibições de catálogo, como:

  • As leituras do servidor de página são adicionadas aos seguintes eventos estendidos:

    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • consulta-store_execution_runtime_info

  • ActualPageServerReads/ActualPageServerReadAheads são adicionados ao XML do plano de consulta para planos reais. Por exemplo:

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

Nota

Para exibir esses atributos na janela de propriedades do plano de consulta, é necessário o SSMS 18.3 ou posterior.

Estatísticas de arquivos virtuais e contabilidade de E/S

No Banco de Dados SQL do Azure, o DMF sys.dm_io_virtual_file_stats() é a principal maneira de monitorar a E/S do Banco de Dados SQL. As características de IO no Hyperscale são diferentes devido à sua arquitetura distribuída. Nesta seção, nos concentramos em IO (leituras e gravações) para arquivos de dados, como visto neste DMF. No Hyperscale, cada arquivo de dados visível neste DMF corresponde a um servidor de página remoto. O cache RBPEX mencionado aqui é um cache local baseado em SSD, que é um cache sem cobertura na réplica de computação.

Uso do cache RBPEX local

O cache RBPEX local existe na réplica de computação, no armazenamento SSD local. Assim, a E/S contra esse cache é mais rápida do que a E/S contra servidores de página remotos. Atualmente, sys.dm_io_virtual_file_stats() em um banco de dados Hyperscale tem uma linha especial relatando a E/S em relação ao cache RBPEX local na réplica de computação. Esta linha tem o valor de 0 para ambas as database_id file_id colunas. Por exemplo, a consulta abaixo retorna estatísticas de uso do RBPEX desde a inicialização do banco de dados.

select * from sys.dm_io_virtual_file_stats(0,NULL);

Uma proporção de leituras feitas no RBPEX para leituras agregadas feitas em todos os outros arquivos de dados fornece a taxa de acertos do cache RBPEX. O contador também está exposto nos contadores RBPEX cache hit ratio de desempenho do Detran sys.dm_os_performance_counters.

Leitura de dados

  • Quando as leituras são emitidas pelo mecanismo de banco de dados do SQL Server em uma réplica de computação, elas podem ser atendidas pelo cache RBPEX local ou por servidores de página remotos ou por uma combinação dos dois se lerem várias páginas.
  • Quando a réplica de computação lê algumas páginas de um arquivo específico, por exemplo, file_id 1, se esses dados residirem apenas no cache RBPEX local, todas as E/S dessa leitura serão contabilizadas em relação ao file_id 0 (RBPEX). Se alguma parte desses dados estiver no cache RBPEX local e outra parte estiver em um servidor de página remoto, a E/S será contabilizada para file_id 0 para a parte servida pelo RBPEX e a parte servida pelo servidor de página remoto será contabilizada para o file_id 1.
  • 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 não tiver alcançado o LSN solicitado, a leitura na réplica de computação aguardará até que o servidor de página se recupere antes que a página seja retornada à réplica de computação. Para qualquer leitura de um servidor de página na réplica de computação, você verá o tipo de espera PAGEIOLATCH_* se estiver aguardando nessa E/S. No Hyperscale, esse tempo de espera inclui o tempo para recuperar 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.
  • Grandes leituras, como read-ahead, geralmente são feitas usando leituras "Scatter-Gather". Isso permite leituras de até 4 MB de páginas por vez, consideradas uma única leitura no mecanismo de banco de dados do SQL Server. No entanto, quando os dados que estão sendo lidos estão no RBPEX, essas leituras são contabilizadas como várias leituras individuais de 8 KB, uma vez que o pool de buffers e o RBPEX sempre usam páginas de 8 KB. Como resultado, o número de IOs de leitura visto em relação ao RBPEX pode ser maior do que o número real de IOs realizadas pelo mecanismo.

Gravações de dados

  • A réplica de computação primária não grava diretamente nos 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 que acontecem na réplica de computação são predominantemente gravações no RBPEX local (file_id 0). Para gravações em arquivos lógicos maiores que 8 KB, ou seja, aquelas feitas usando Gather-write, cada operação de gravação é convertida em várias gravações individuais de 8 KB no RBPEX, uma vez que o pool de buffers e o RBPEX sempre usam páginas de 8 KB. Como resultado, o número de IOs de gravação visto em relação ao RBPEX pode ser maior do que o número real de IOs executadas pelo mecanismo.
  • Arquivos não-RBPEX, ou arquivos de dados diferentes de file_id 0 que correspondem a servidores de página, também mostram gravações. Na camada de serviço Hyperscale, essas gravações são simuladas, porque as réplicas de computação nunca gravam diretamente nos servidores de página. IOPS de gravação e taxa de transferência são contabilizados como ocorrem na réplica de computação, mas a latência para arquivos de dados diferentes de file_id 0 não reflete a latência real das gravações do servidor de página.

Gravações de log

  • No cálculo primário, uma gravação de log é contabilizada no file_id 2 de sys.dm_io_virtual_file_stats. Uma gravação de log na computação primária é uma gravação na Zona de aterrissagem do log.
  • Os registros de log não são protegidos na réplica secundária em uma confirmação. No Hyperscale, o log é aplicado pelo serviço de log às réplicas secundárias de forma assíncrona. Como as gravações de log não ocorrem em réplicas secundárias, qualquer contabilização de E/S de log nas réplicas secundárias é apenas para fins de rastreamento.

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

Em um banco de dados não Hyperscale, IOPS de leitura e gravação combinadas em arquivos de dados, relativas ao limite de IOPS de dados de governança de recursos, são relatadas em exibições sys.dm_db_resource_stats e sys.resource_stats, na avg_data_io_percent coluna. O mesmo valor é relatado no portal do Azure como Porcentagem de E/S de Dados.

Em um banco de dados Hyperscale, esta coluna relata a utilização de IOPS de dados em relação ao limite de armazenamento local somente na réplica de computação, especificamente IO em relação a RBPEX e tempdb. Um valor de 100% nesta coluna indica que a governança de recursos está limitando as IOPS de armazenamento local. Se isso estiver correlacionado com um problema de desempenho, ajuste a carga de trabalho para gerar menos E/S ou aumente o objetivo do serviço de banco de dados para aumentar o limite máximo de IOPSde dados de governança de recursos. Para governança de recursos de leituras e gravações RBPEX, o sistema conta E/S individuais de 8 KB, em vez de E/S maiores que podem ser emitidas pelo mecanismo de banco de dados do SQL Server.

A E/S de dados em servidores de página remotos não é relatada em exibições de utilização de recursos ou no portal, mas é relatada no DMF sys.dm_io_virtual_file_stats(), conforme observado anteriormente.

Recursos adicionais