Aumento de esperas durante o ponto de verificação após a atualização para melhor armazenamento

Quando migramos de uma matriz flash all mais antiga para uma matriz flash all mais recente (fornecedor diferente, mas bem estabelecido), começamos a ver esperas aumentadas no SQL Sentry durante os pontos de verificação.

Versão: SQL Server 2012 Sp4

Em nosso armazenamento antigo, nossas esperas eram de cerca de 2k com "picos" a 2500 durante um ponto de verificação. Com o novo armazenamento, os picos são tipicamente 10k com picos próximos a 50k. Sentinela nos aponta mais para o PAGEIOLATCHwatis. Fazendo nossa própria análise, parece ser uma combinação de PAGEIOLATCH and PAGELATCHesperas. Usando o Perfmon, geralmente podemos dizer que, quanto mais páginas verificamos, mais esperas recebemos, mas estamos apenas liberando ~ 125 mb durante o ponto de verificação. Nossa carga de trabalho é principalmente gravações (inserções / atualizações principalmente).

O fornecedor de armazenamento nos provou que a matriz de conexão direta do Fibre Channel está respondendo a menos de 1 ms durante esses eventos de ponto de verificação. O HBA também confirma os números da matriz. Também não acreditamos que seja um problema de enfileiramento do HBA, pois a profundidade da fila nunca foi superior a 8. Também tentamos um HBA mais recente, alterando as configurações de ZIO, acelerador de execução e profundidade da fila sem sucesso. Também aumentamos a memória do servidor de 500 GB para 1 TB sem alterações. Durante o processo do ponto de verificação, vemos de 2 a 4 núcleos individuais (de 16) aumentar para 100%, mas a CPU geral é de cerca de 20%. O BIOS também está configurado para alto desempenho. Curiosamente, porém, vemos que as CPUs geralmente estão em um estado de suspensão C2, embora tenhamos desativado isso, então ainda estamos pesquisando por que o estado de suspensão passa de C1.

Podemos ver que quase todas as esperas estão nas páginas de dados com um ocasional tipo de página PFS do DCM. As esperas estão nos bancos de dados do usuário, não no tempdb. Também vemos que as esperas terminam em várias páginas de dados, com alguns SPIDs aguardando na mesma página. O design do banco de dados possui alguns pontos ativos de inserção, mas o mesmo design estava em vigor no armazenamento antigo.

Executando um loop desta consulta 100 vezes, conseguimos capturar quantos SPIDs estavam aguardando no disco x na memória

SELECT
    [owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type]
order by 1
GO 100

A coisa "legal" é que podemos facilmente reproduzir o problema em nosso ambiente de perf, que possui a mesma matriz de modelo e especificações de servidor semelhantes. Eu apreciaria qualquer pensamento sobre onde mais procurar ou como diminuir o problema. No momento, nossos próximos testes incluem: um novo servidor com placa-mãe mais nova e mais CPUs; desabilitar o datakeeper SIOS (mesmo que isso tenha sido implementado com armazenamento antigo); marca HBA diferente.

exec sp_Blitz @outputtype = 'markdown'

Prioridade 5: Confiabilidade : - Módulos de terceiros perigosos - Sophos Limited - Proteção de saturação de buffer da Sophos - SOPHOS ~ 2.DLL - módulo de terceiros perigosos suspeito está instalado.

Prioridade 200: Informativo : - Nó de Cluster - Este é um nó em um cluster. - TraceFlag On - o sinalizador de rastreamento 1117 está ativado globalmente. - O sinalizador de rastreamento 1118 está ativado globalmente. - O sinalizador de rastreamento 3226 está ativado globalmente.

Prioridade 200: Licenciamento : - Recursos da Enterprise Edition em uso * xxxxx - O banco de dados [xxxxxx] está usando Compressão. Se esse banco de dados for restaurado em um servidor Standard Edition, a restauração falhará nas versões anteriores ao 2016 SP1. * xxxxx - O banco de dados [xxxxxx] está usando o Particionamento. Se esse banco de dados for restaurado em um servidor Standard Edition, a restauração falhará nas versões anteriores ao 2016 SP1.

Prioridade 240: Estatísticas de espera : - Nenhuma espera significativa detectada - Este servidor pode estar ocioso ou alguém pode ter limpo as estatísticas de espera recentemente.

Prioridade 250: Informações do Servidor: - Hardware - Processadores lógicos: 16. Memória física: 512GB. - Hardware - NUMA Config - Nó: 0 Estado: ONLINE agendadores online: 8 Agendadores offline: 0 Grupo de processadores: 0 Nó de memória: 0 Memória VAS reservada GB: 1177 - Nó: 1 Estado: ONLINE agendadores online: 8 agendadores offline: 0 Processador Grupo: 0 Nó de memória: 1 Memória VAS reservada GB: 0 - Plano de energia - Seu servidor possui CPUs de 3,50 GHz e está no modo de energia de alto desempenho - Última reinicialização do servidor - 4 de julho de 2018 4:56 - Última reinicialização do SQL Server - 5 de julho 2018 5:11 - SQL Server Service - Versão: 11.0.7462.6. Nível do patch: SP4. Edição: Enterprise Edition (64 bits). Grupos de disponibilidade ativados: 1. Status do gerente de grupos de disponibilidade: 1 - Servidor virtual - Tipo: (HYPERVISOR) - Versão do Windows - Você está executando uma versão bastante moderna do Windows: Server 2012R2 era, versão 6.3

Prioridade 200: configuração de servidor não padrão: - Agent XPs - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - padrão de compactação de backup - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - limiares do processo bloqueado - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 20. - limite de custo para paralelismo - Esta opção sp_configure foi alterada. Seu valor padrão é 5 e foi definido como 30. - Database Mail XPs - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - máximo grau de paralelismo - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 8. - max server memory (MB) - Esta opção sp_configure foi alterada. Seu valor padrão é 2147483647 e foi definido como 496640. - min server memory (MB) - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 8196. - otimizar para cargas de trabalho ad hoc - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - acesso remoto - Esta opção sp_configure foi alterada. Seu valor padrão é 1 e foi definido como 0. - conexões administrativas remotas - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - procurar procs de inicialização - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - mostrar opções avançadas - Esta opção sp_configure foi alterada. Seu valor padrão é 0 e foi definido como 1. - xp_cmdshell - Esta opção sp_configure foi alterada.

Hmm. Você mostra spids aguardando durante o ponto de verificação, mas não quanto tempo espera em média / agregado (o que, honestamente, seria tudo o que me interessa). Faça uma análise estatística de espera diferencial para ver se a duração é preocupante. Além disso, quais são exatamente as duas esperas no seu gráfico? Se você estiver recebendo muitas esperas de concessão de memória com 1 TB de RAM em jogo, precisamos ter uma discussão diferente. :-D

A velocidade de gravação de 125 MB durante o ponto de verificação: é que APENAS o ponto de verificação grava ou TUDO? De qualquer maneira, parece baixo para o armazenamento totalmente em flash. Você comparou o referido armazenamento para vários padrões de gravação e, em caso afirmativo, qual número você recebeu?

Não sabemos ao certo por que o comportamento do nosso SQL Server mudou (e temos evidências de que isso aconteceu antes da troca de armazenamento), mas a ativação de pontos de verificação indiretos para os DBs do usuário corrigiu o problema para nós.