Partilhar via

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

Aplica-se a: do Banco de Dados SQL do Azure

Para solucionar problemas de desempenho em um banco de dados Hyperscale, as metodologias gerais de otimização de desempenho SQL são o ponto de partida de qualquer investigação de desempenho. No entanto, dada a arquitetura distribuída do Hyperscale, dados de diagnóstico adicionais podem precisar ser considerados. Este artigo descreve dados de diagnóstico específicos da hiperescala.

Tempos de espera de taxas de registo reduzidos

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 de governança de taxa de log. O limite de taxa de log é exposto na primary_max_log_rate coluna em sys.dm_user_db_resource_governance.

Às vezes, a taxa de geração de logs na réplica de computação primária deve ser reduzida para manter os SLAs (Service Level Agreements, contratos de nível de serviço) de capacidade de recuperação. Por exemplo, isso pode acontecer quando um servidor de página ou outra réplica de computação está significativamente atrasada na aplicação de novas entradas de log do serviço de log. Se nenhum componente do Hyperscale estiver atrasado, o mecanismo de governança de taxa de log permitirá que a taxa de geração de log atinja 150 MiB/s por banco de dados para hardware otimizado para memória de séries premium e premium. Para hardware de série padrão, a taxa máxima de log é de 100 MiB/s por banco de dados. Para pools elásticos, a taxa máxima de log é de 150 MiB/s por pool para hardware de série premium e hardware otimizado para memória de série premium, e 125 MiB/s por pool para outro hardware.

Os seguintes tipos de espera aparecem no sys.dm_os_wait_stats quando a taxa de log é reduzida:

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

A função de gerenciamento dinâmico (DMF) sys.dm_hs_database_log_rate() fornece mais detalhes para ajudá-lo a entender a redução da taxa de log, se houver. Por exemplo, ele pode dizer qual réplica secundária específica está atrasada na aplicação de registos de log e qual é o tamanho total do log de transações que ainda não foi aplicado.

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 de pool de buffer 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 mantém.

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

Várias vistas geridas dinamicamente (DMVs) e eventos estendidos têm colunas e campos que especificam o número de leituras remotas de um servidor de páginas, que pode ser comparado com o total de leituras. O Repositório de Consultas também captura as leituras dos servidores de páginas nas estatísticas de tempo de execução das consultas.

  • As colunas para leituras do servidor de páginas de relatórios estão disponíveis em DMVs de execução e visualizaçõ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 18.3 ou posterior.

Estatísticas de ficheiros virtuais e contabilidade de entrada/saída

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 no Hyperscale são diferentes devido à sua arquitetura distribuída . Nesta seção, nos concentramos na leitura e gravação de E/S, como visto neste DMF.

Para Hyperscale, os dados relevantes são os seguintes: sys.dm_io_virtual_file_stats()

  • As linhas onde o database_id valor corresponde ao valor retornado pela função DB_ID e onde o file_id valor é diferente de 2, correspondem a servidores de página. Comumente, cada linha corresponde a um servidor de página. No entanto, para arquivos maiores, vários servidores de página são usados.

    • A linha com file_id 2 corresponde ao log de transações.

  • As linhas em que o valor na coluna database_id é 0 correspondem ao cache SSD local na réplica de computação.

Uso de 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, a E/S nesse cache é mais rápida do que a E/S em servidores de página. Em um banco de dados Hyperscale ou pool elástico, sys.dm_io_virtual_file_stats() tem linhas especiais relatando estatísticas de E/S para o cache SSD local. Essas linhas têm o valor de 0 para a database_id coluna. Por exemplo, a consulta a seguir 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 entre as leituras agregadas dos arquivos de cache SSD local e as leituras agregadas de todos os outros arquivos de dados é a proporção de acertos do cache SSD local. Esta métrica é fornecida pelos contadores de desempenho RBPEX cache hit ratio e RBPEX cache hit ratio base, disponíveis no sys.dm_os_performance_counters, DMV.

Leitura de dados

  • Quando as leituras são emitidas pelo mecanismo de banco de dados em uma réplica de computação, elas podem ser servidas pelo cache SSD local ou por servidores de página, ou por uma combinação dos dois se lerem várias páginas.

  • Quando a réplica de cálculo lê páginas de um ficheiro de dados específico (por exemplo, o ficheiro com file_id 1), se estes dados residirem apenas na cache local SSD, todas as operações de E/S dessa leitura serão contabilizadas em relação aos ficheiros de cache SSD locais, onde database_id é 0. Se alguma parte desses dados estiver no cache SSD local e outra parte estiver em servidores de página, o IO será contabilizado parcialmente para os arquivos de cache SSD locais e parcialmente para os arquivos de dados correspondentes aos servidores de página.

  • 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 alcançou o LSN solicitado, a leitura na réplica de computação aguarda até que o servidor de página se recupere antes que a página seja retornada. Para qualquer leitura de um servidor de página na réplica de computação, observa-se um tipo de espera PAGEIOLATCH_* se estiver à espera dessa 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.

  • Leituras grandes, como leituras antecipadas, geralmente são feitas usando leituras dispersão-coleta. Isso permite ler até 4 MB como uma única operação de leitura de E/S. No entanto, quando os dados que estão sendo lidos estão no cache SSD local, essas leituras são contabilizadas 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 E/S de leitura observado no cache SSD local pode ser maior do que o número real de E/S executadas pelo motor.

Gravações de dados

  • A réplica de computação principal não grava diretamente nos servidores de páginas. Em vez disso, os registros de log do serviço de log são reproduzidos nos servidores de página correspondentes.

  • As escritas na réplica de computação são predominantemente realizadas no cache SSD local (database_id 0). Para escritas maiores que 8 KB, isto é, aquelas feitas usando gather-write, cada operação de escrita é convertida em várias escritas individuais de 8 KB no cache SSD local, visto que o pool de buffers e o cache SSD local usam sempre páginas de 8 KB. Como resultado, o número de operações de E/S de gravação observadas no cache SSD local pode ser maior do que o número real de operações de E/S executadas pelo motor.

  • Arquivos de dados diferentes de database_id 0 que correspondem a servidores de página também podem mostrar gravações. No Hyperscale, estas operações de gravação são simuladas, porque as réplicas de cálculo nunca gravam diretamente nos servidores de página. As estatísticas de E/S são contabilizadas à medida que ocorrem na réplica de computação. IOPS de gravação, taxa de transferência e latência vistas em uma réplica de computação para arquivos de dados diferentes de database_id 0 não refletem as estatísticas reais de E/S de gravações que ocorrem em servidores de página.

Escritas de log

  • Na réplica de computação primária, os registos de log são contabilizados em sys.dm_io_virtual_file_stats() em file_id 2.

  • Ao contrário dos grupos de disponibilidade, quando uma transação é confirmada na réplica de computação primária, os registros de log não são gravados definitivamente na réplica secundária. Em Hyperscale, o log é consolidado no serviço de logs e aplicado à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 em sys.dm_io_virtual_file_stats() nas réplicas secundárias não deve ser usada como estatísticas de E/S de log de transações.

Entrada/Saída de dados em estatísticas de utilização de recursos

Em um banco de dados não Hyperscale, os IOPS de leitura e gravação combinadas contra arquivos de dados, em relação ao limite de IO 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. Os 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 relatados como a porcentagem de E/S de dados métricas do Azure Monitor para bancos de dados e pools elásticos.

Em um banco de dados Hyperscale, estas colunas e métricas relatam a utilização de E/S de dados relativa ao limite de armazenamento SSD local apenas na réplica de computação, que inclui E/S em relação ao cache SSD local e ao banco de dados 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 a capacidade de computação para melhorar a gestão de recursos e o limite máximo de IOPS de dados . Para a gestão de recursos em leituras e gravações do cache SSD local, o sistema conta operações de IO individuais de 8 KB, em vez de maiores operações de IO que podem ser emitidas pelo motor de base de dados.

As operações de E/S de dados em servidores de página não são relatadas nas visões de utilização de recursos ou por meio de métricas do Azure Monitor, mas são relatadas em sys.dm_io_virtual_file_stats() conforme descrito anteriormente.

Conteúdo relacionado

  • Last updated on