O Resource Monitor insere uma condição de não rendimento em um servidor que executa SQL Server

Este artigo fornece mais informações sobre o não rendimento do Resource Monitor.

Versão original do produto: SQL Server
Número de KB original: 2216485

Sintomas

Em um servidor que está executando o Microsoft SQL Server 2008 ou uma versão posterior, a tarefa do Resource Monitor registra a seguinte mensagem a cada 5 segundos:

Date_And_Time Server Using 'dbghelp.dll' version '4.0.5'
Date_And_TimeServer **Dump thread - spid = 0, PSS = 0x0000000000000
000, EC = 0x0000000000000000
Date_And_TimeLogon Login succeeded for user 'OPENTEXT\sqlcrmusr'. Connection: trusted. [CLIENT:
IP_Address]
Date_And_Timespid78 Error: 4014, Severity: 20, State: 2.
Date_And_Timespid78 A fatal error occurred while reading the input stream from the network. The session will be terminated.
Date_And_TimeServer ***Stack Dump being sent to Drive:\MSSQL2005\LOG\SQLDump####.txt
Date_And_TimeServer * *******************************************************************************
Date_And_TimeServer *
Date_And_TimeServer * BEGIN STACK DUMP:
Date_And_TimeServer *
Date_And_Timespid 0
Date_And_TimeServer *
Date_And_TimeServer * Non-yielding Resource Monitor
Date_And_TimeServer *
Date_And_TimeServer * *******************************************************************************
Date_And_TimeServer * -------------------------------------------------------------------------------
Date_And_TimeServer * Short Stack Dump
Date_And_TimeServer Stack Signature for the dump is 0x000000000000005C
Date_And_Time,Server,Unknown,Resource Monitor (0x9b0) Worker 0x0000000003A2C1C0 appears to be non-yielding on
Node_#. Memory freed: 0 KB. Approx CPU Used: kernel 0 msnull user 0 msnull Interval:
Interval_value.

Motivo

A tarefa do Monitor de Recursos acorda periodicamente para escutar eventos de memória classificados como baixos, altos ou estáveis. O monitor notifica os assinantes do evento quando esses eventos ocorrem.

Esses eventos de memória podem ser externos a SQL Server. Eventos externos incluem notificações do sistema operacional e são em todo o sistema. Outros eventos são internos para SQL Server. Eventos internos incluem notificações do pool de buffers e são em todo o processo. Quando essas notificações são recebidas, vários consumidores de memória cortam o uso da memória.

Observação

Os consumidores podem ser funcionários de memória que são repositórios de cache, repositórios de usuários ou repositórios de objetos.

Se determinados consumidores de memória usarem uma grande quantidade de memória, o corte que os consumidores executam pode levar muito tempo para se preparar.

A tarefa Monitor do Agendador é executada a cada 5 segundos. O Monitor de Agendamento verifica se o Monitor de Recursos passou de um consumidor para outro nos últimos 60 segundos. Quando o Monitor do Agendador detecta que o Monitor de Recursos não passou por um consumidor por 60 segundos, o Monitor de Agendamento interpreta esse cenário como o Monitor de Recursos inserindo um estado não produtivo. Essa interpretação faz com que o Monitor de Agendamento registre a mensagem de erro mencionada na seção Sintomas.

Observação

Começando com SQL Server 2019, o intervalo de 60 segundos é aumentado para 120 segundos. Esse aumento reduz a frequência dessas notificações de diagnóstico. E reduz a geração de arquivos de despejo de memória.

Essas mensagens também serão geradas se a taxa na qual o Monitor de Recursos libera a memória for menor que 2 MB a cada 5 segundos.

Essas mensagens são apenas uma indicação de que o Monitor de Recursos está ocupado limpando grandes consumidores. Essas mensagens não indicam necessariamente um problema com o próprio Resource Monitor.

Resolução

Começando com os seguintes pacotes de serviço, a mensagem do Monitor de Recursos que não produz se estende para isolar facilmente o gerenciador de memória que leva à condição de não rendimento:

  • Service Pack 2 do Microsoft SQL Server 2008
  • Service Pack 1 do Microsoft SQL Server 2008 R2

A nova mensagem se assemelhará ao seguinte exemplo:

Resource Monitor (0x9b0) Worker 0x0000000003A2C1C0 appears to be non-yielding on Node Node_#. Memory freed: 0 KB. Last wait: > lastwaittype. Last clerk: type clerk_type, name clerk_name. Approx CPU Used: kernel 0 ms, user 0 ms, Interval: Interval_value.

Veja a seguir as descrições dos vários campos que são usados nesta mensagem:

  • Memória liberada: Esse campo é a quantidade de memória liberada pelo Resource Monitor para o intervalo especificado. É medido em quilobytes. Se a taxa na qual a memória é liberada não exceder 2 MB a cada 5 segundos, o Monitor do Agendador detectará essa condição como uma condição que não produz.

  • Última espera: Esse campo é o último tipo de espera para o thread do Resource Monitor. Você pode usar esse campo em combinação com o Approx CPU Used campo. Essa combinação de campo pode identificar se o thread do Resource Monitor está em execução ou aguardando uma parte significativa do intervalo.

  • Último funcionário: Esse campo é o tipo e o nome do funcionário de memória que estava cortando sua memória quando a condição de não rendimento ocorreu.

  • CPU aproximada usada: Esse campo é o kernel e o tempo de usuário usados pelo Resource Monitor, conforme medido em milissegundos. Você pode usar esse campo junto com outros campos para verificar se o Resource Monitor está progredindo durante o intervalo especificado.

  • Intervalo: Esse campo é o tempo decorrido desde que o último funcionário foi notificado, conforme medido em milissegundos.

Você pode usar essa mensagem para identificar a origem da notificação de memória baixa. Você também pode usar as entradas RING_BUFFER_RESOURCE_MONITOR do momento da mensagem.

Recursos

Para obter mais informações sobre como interpretar o monitor RING_BUFFER_RESOURCE, confira a seguinte postagem no blog techcommunity:

A tarefa Do Monitor de Recursos pode solucionar problemas de desempenho relacionados à memória no SQL Server. SQL Server escuta e responde às notificações de memória. Para obter mais informações sobre esses itens, consulte os seguintes artigos do blog MSDN: