Nossos 5 bancos de dados principais são executados em um SQL Server 2016 SP2 Enterprise físico (2 * 8 núcleos, 512 GB, Hypertreading) em um único Grupo de Disponibilidade e, às vezes, recebemos erros de que o tempo limite de concessão expirou. Meu entendimento é que, se a concessão não puder ser atualizada, haverá um problema em todo o sistema.
Quando verifico a saída de sp_server_diagnostics(arquivos *SQLDIAG*.xel), na pasta de log da réplica primária, na hora do tempo limite sempre encontro operações de E/S pendentes.
<ioSubsystem ioLatchTimeouts="0" intervalLongIos="0" totalLongIos="1">
<longestPendingRequests>
<pendingRequest duration="26566" filePath="\?\F:\SqlLogs\db1.ldf" offset="80824832" handle= "0x8d10" /> <pendingRequest duration="1987" filePath="\?\O:\SqlLogs\db2.ldf" offset="3880740352" handle="0x1330" /> <pendingRequest duration="1093" filePath="\ ?\O:\SqlLogs\db3.ldf" offset="288143360" handle="0x132c" /> <pendingRequest duration="974" filePath="\?\O:\SqlLogs\db3.ldf" offset="288145408" handle="0x132c" /> <pendingRequest duration="937" filePath="\?\O:\SqlLogs\db3.ldf"offset="288146944" handle="0x132c" />
</longestPendingRequests>
</ioSubsystem>
Isto é o que encontro no clusterlog da réplica primária:
WARN [RES] Grupo de Disponibilidade do SQL Server: [hadrag] Falha ao recuperar a coluna de dados. Código de retorno -1
ERR [RES] Grupo de Disponibilidade do SQL Server: [hadrag] Falha detectada, pulsação de diagnóstico perdida
ERR [RES] Grupo de Disponibilidade do SQL Server <AG_Name>: [hadrag] O Grupo de Disponibilidade não está íntegro com HealthCheckTimeout e FailureConditionLevel
ERR [ RES] Grupo de Disponibilidade do SQL Server <AG_Name>: [hadrag] Resource Alive resultado 0.
ERR [RES] Grupo de Disponibilidade do SQL Server: [hadrag] Falha detectada, pulsação de diagnóstico perdida
ERR [RES] Grupo de Disponibilidade do SQL Server <AG_Name>: [ hadrag] O Grupo de Disponibilidade não está íntegro com HealthCheckTimeout e FailureConditionLevel fornecidos
ERR [RES] Grupo de Disponibilidade do SQL Server <AG_Name>: [hadrag] Resource Alive resultado 0.
WARN [RHS] O recurso AG_Name IsAlive indicou falha.
Estes são os erros no log de erros do SQL Server:
Erro: 19407, gravidade: 16, estado: 1
grupo de disponibilidade de hospedagem do SQL Server 'AG_Name' não recebeu um sinal de evento de processo do cluster de failover do Windows Server dentro do período de tempo limite de concessão.Erro: 19407, gravidade: 16, estado: 1
A concessão entre o grupo de disponibilidade 'AG_Name' e o cluster de failover do Windows Server expirou. Ocorreu um problema de conectividade entre a instância do SQL Server e o cluster de failover do Windows Server. Para determinar se o grupo de disponibilidade está fazendo failover corretamente, verifique o recurso de grupo de disponibilidade correspondente no cluster de failover do Windows Server.Always On: a réplica local do grupo de disponibilidade 'AG_Name' está ficando offline porque a concessão expirou ou a renovação da concessão falhou. Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do usuário.
Esta é a saída de SELECT @@version:
Microsoft SQL Server 2016 (SP2-CU15) (KB4577775) - 13.0.5850.14 (X64) 17 de setembro de 2020 22:12:45 Copyright (c) Microsoft Corporation Enterprise Edition: licenciamento baseado em núcleo (64 bits) no Windows Server 2012 R2 Padrão 6.3 (Build 9600: )
Em nosso monitoramento não há sinais de alto uso de CPU. Além disso, nenhum despejo de memória é criado no momento do problema.
Como resultado desse tempo limite, o serviço WSFC reinicia o recurso de cluster 'AG_Name'. Depois que este recurso é reiniciado, tudo funciona perfeitamente novamente.
O que não entendo é: como as solicitações de IO lentas podem causar um tempo limite de concessão? Muitas solicitações de E/S pendentes podem causar um tempo limite de concessão?
Não, solicitações de E/S lentas não podem causar um tempo limite de concessão diretamente.
No entanto, se o servidor estiver completamente sobrecarregado (CPU em 100%), isso pode causar solicitações de E/S pendentes e tempos limite de concessão. O tempo limite de concessão padrão é de 20 segundos e sua E/S pendente é de 26 segundos. CPU alta ou algum outro problema no nível do servidor / SO é mais provável que seja o problema aqui.
Outra causa é que o SQL Server encontrou um erro grave e está gerando arquivos de despejo (o que faz com que o processo seja pausado, potencialmente longo o suficiente para o WSFC pensar que a concessão expirou).
Veja a documentação para mais algumas possibilidades:
Você deve revisar o log de erros do SQL Server para ver se há despejos sendo criados. Se você tiver monitoramento desde o momento desses incidentes, também poderá verificar se a CPU está no limite.
Depois de verificar as estatísticas de espera em nossa ferramenta de monitoramento, notei que no momento do problema havia dois tipos de espera principais com um tempo de espera de 526000 ms/s, PREEMPTIVE_SP_SERVER_DIAGNOSTICS e PREEMPTIVE_HADR_LEASE_MECHANISM .
Se eu interpretar isso corretamente, a parte PREEMPTIVE significa que um thread fora do SQLOS está executando os comandos. Neste caso, executando SP_SERVER_DIAGNOSTICS e renovando a concessão.
O alto tempo de espera mostra que o SQL Server estava aguardando a conclusão desses threads. Então eu acho que isso foi um problema do sistema operacional que não estava respondendo.
Nosso administrador do sistema também mencionou que no momento do tempo limite havia vários avisos com o event-id 153 no log do sistema:
Portanto, minha conclusão é devido aos problemas de disco, o sistema operacional não estava respondendo dentro das configurações de tempo limite definidas e fez com que o recurso de cluster fosse reiniciado.