Temos um SQL Server 2022 CU13 Enterprise em uma VM Windows 2022 com 8 vCPU. O processo sqlserver.exe mostra uma alta utilização da CPU entre 10-15%, mesmo quando não há carga gerada pelo usuário (o que significa que não há conexão do usuário no momento, até mesmo o SQL Server Agent é interrompido para eliminar toda carga que não seja do sistema) em o servidor. O tipo de espera dominante é SOS_SCHEDULER_YELD nesse tempo ocioso.
Essa atividade do servidor também bloqueia a interrupção do serviço SQL Server. Uma tentativa de interromper o serviço resulta em uma espera interminável e o processo de serviço do Windows precisa ser encerrado para "parar". Após a reinicialização, a utilização funciona perfeitamente por algum tempo (o servidor inativo tem */- 0 utilização de CPU), mas após algum período de tempo (algumas horas ou alguns dias no máximo) com a carga do usuário em execução, o problema volta novamente . Significa que a utilização é maior do que deveria ser com a carga do usuário gerada e, novamente, após a carga ser interrompida (sem conexões do usuário), a utilização permanece alta conforme mencionado acima...
Não há mensagens suspeitas no log de erros, na sessão de integridade do XE, no log de eventos do Windows...
Aqui está a visualização do Activity Monitor no servidor durante o período ocioso descrito acima:
Após alguma investigação, provavelmente identifiquei o SPID, que causa essa utilização. Parece ser um SPID do sistema (SPID 37 no momento da investigação) e consome cerca de 10 segundos de tempo de CPU em um período de 10 segundos (veja a saída da Consulta 4 abaixo). O database_id do SPID parece estar mudando entre o mestre (database_id = 1) e um dos bancos de dados do usuário (database_id = 10). Apenas os IDs de bancos de dados 1 e 10 parecem estar envolvidos nesta atividade SPID. O SPID também está gerando uma alocação cada vez maior no tempdb (veja a saída da Consulta 3 abaixo).
Aqui está a saída do sys.dm_exec_request ao mesmo tempo em que a imagem do Activity Monitor acima foi tirada (o spid problemático é o 37):
Aqui está a saída de sp_WhoIsActive ao mesmo tempo:
Aqui está um cálculo do tempo de CPU consumido para o SPID durante o período de 10 segundos:
Pelo que entendi, parece ser uma atividade do Service Broker. No entanto, não há Service Broker habilitado no banco de dados mestre nem no banco de dados do usuário. Não usamos ativamente o Service Broker em nossos bancos de dados. Não tenho ideia do que possa ser essa atividade do corretor e com que atividade do sistema ela pode estar conectada. Não há nenhum recurso "incomum" usado no servidor ou no banco de dados do usuário, apenas um "conjunto básico de recursos comuns", o único "recurso incomum" é o TDE habilitado.
Alguma idéia de como posso investigar melhor a causa raiz desse problema (do que se trata essa atividade do corretor) e como posso me livrar dele?
Eu descobri qual é a causa raiz do comportamento declarado acima após algumas tentativas no final. Havia o Query Store habilitado no banco de dados "problemático" e a carga gerada pelo usuário consiste principalmente em consultas ad-hoc. Isso resultou na situação em que o Query Store foi preenchido rapidamente e o "procedimento de limpeza baseado em tamanho" foi acionado. Essa limpeza baseada no tamanho parece ser a fonte da utilização da CPU.
A incapacidade de desligar "pacificamente" o serviço SQL Server parece ser causada pelo fato de o armazenamento de consultas estar aguardando para liberar alguns dados no disco (isso pode ser evitado usando o sinalizador de rastreamento 7745).
De qualquer forma isso abre uma nova questão relacionada ao comportamento do Query Store ( Broken Query Store )