Freigeben über

Desafio: Resource Monitor e Paginação de Memória

  • Artikel

Esse é um desafio bastante difícil e não ficaria surpreso se aparecesse algo assim na certificação do Microsoft Certified Master. Esse problema envolve o diagnóstico da quantidade de memória disponível no servidor, mas sob uma perspectiva mais abrangente. Torna-se necessário compreender o cenário como um todo ao invés de analisar os erros pontualmente.

Estava lendo o artigo de suporte KB 918483 relacionado com alta utilização de memória que tem um trecho do ERRORLOG:

How to reduce paging of buffer pool memory in the 64-bit version of SQL Server
https://support.microsoft.com/kb/918483/en-us

2009-05-05 15:43:56.01 Server Resource Monitor (0x13c43) Worker 0x0412C1E8 appears to be non-yielding on Node 0. Memory freed: 34152 KB. Approx CPU Used: kernel 171 ms, user 140 ms, Interval: 125093. 2009-05-05 12:54:52.18 Server * ******************************************************************************* 2009-05-05 12:54:52.18 Server * BEGIN STACK DUMP: 2009-05-05 12:54:52.18 Server * 05/05/08 12:54:52 spid 0 2009-05-05 12:54:52.18 Server * Non-yielding Resource Monitor 2009-05-05 12:54:52.18 Server * ******************************************************************************* 2009-06-10 09:13:53.44 Server * ******************************************************************************* 2009-06-10 09:13:53.44 Server * BEGIN STACK DUMP: 2009-06-10 09:13:53.44 Server * 06/10/09 09:13:53 spid 0 2009-06-10 09:13:53.44 Server * Non-yielding IOCP Listener 2009-06-10 09:13:53.44 Server * ******************************************************************************* 2009-06-10 09:13:55.85 spid2s LazyWriter: warning, no free buffers found. 2009-07-15 13:27:45.35 spid4s AppDomain xx (SQLCLR.dbo[runtime].xx) is marked for unload due to memory pressure. 2009-07-15 13:27:45.35 spid4s AppDomain xx (SQLCLR.dbo[runtime].xx) unloaded. 2009-07-15 13:37:51.42 Logon Error: 17189, Severity: 16, State: 1. 2009-07-15 13:37:51.42 Logon SQL Server failed with error code 0xc0000000 to spawn a thread to process a new login or connection. Check the SQL Server error log and the Windows event logs for information about possible related problems. [CLIENT: xx.xxx.xx.xx]

 

A pergunta é como interpretar todas essas mensagens de erro e por qual motivo que elas aparecem no ERRORLOG.

  1. Qual o motivo do Stack Dump?
  2. Qual a relação entre o Lazy Writer e as mensagens de erro do SQLCLR?
  3. Qual o impacto do erro de Logon?

Por fim, qual problema (provavelmente) ocorreu no servidor que levou a todos esses erros?

Postem os seus comentários e opiniões!

Comments

  • Anonymous
    October 17, 2010
    Cara,não sei se vai estar certo,mas vai o meu pensamento. 1 - O motivo do dump ter sido gerado é que algo de muito GRAVE ocorreu no seu servidor.Se voce não consegue interpretar o tipo de erro,ele gera os arquivos no diretorio de ErrorLogs do SQL para voce enviar para o time de suporte da microsoft para analisar o caso. 2 - O SQL server esta sofrendo pressão de memória,e a relação é que o SQL Server liberou a memória para o SO ou para outra área do sql Server que esta consumindo mais memória do que deveria,nesse caso o SQL Server quando executa "out of memory" fica impossibilitado de executar o lazywriter(responsavel por monitorar a free buffer list,e fazer o flush no disco das paginas menos utilizadas)  gerando o erro  LazyWriter: warning, no free buffers found..Com isso o CLR que também é um consumidor de memória,tem que liberar a memória que esta utilizando,gerando a menssagem de erro. Vale um detalhe,o Non-yielding IOCP Listener (IOCP = I/O completation port),indica que o seu subsistema de disco não esta correspondendo o esperado,indicando que a thread tem que esperar para fazer o I/O,e quando a thread tem que esperar,é nesse momento que é gerado o dump. 3 - Quando um usuario vai fazer logon no sql server,ele precisa de thread,e essa thread passa pelo processador,mas nesse caso ele não vai conseguir alocar a thread no processador,pois as outras threads não querem "sair" do processador,ocorrendo a menssagem de erro, ou o SQL não tem memória para alocar para realizar o logon do usuario. Real problema,o SQL Server não tem memória suficiente para atender todas as querys que estão sendo feitas no servidor,gerando alto consumo do lazywriter,que uma hora não consegue mais executar,devido a falta de memória.O CLR por sua vez tem que liberar a memória que esta utilizando. e também fazendo com que as threads que estão solicitando dados do disco ficam em espera. Como resolver,coloque mais memória no servidor,ou ache as querys que estão mais consumindo memória e tente diminuir o consumo das mesmas. Não sei se esta certo,mas valeu a tentativa....coloca mais desafios desses..... Abraço....!!!!!

  • Anonymous
    October 18, 2010
    Bons palpites Fernando!   1 - Correto, o procedimento ideal é que seja enviado os arquivos de Dump (extensão mdmp) para a equipe de suporte da Microsoft. E você sabe dizer qual a gravidade desse problema?   2 - Parcialmente correto. O lazy writer rodou normalmente e imprimiu o warning que não foram encontrados free buffers. Aqui faltou encaixar os processos do Resource Monitor em relação ao Lazy Writer, CLR e os demais Memory Clerks.   3 - O impacto dos erros é, como você disse, erro de Login. O comportamento descrito é da falta de Thread, que é ligeiramente diferente de dizer Worker Thread. Vale um post para falar da diferença! :) Um ponto importante é o que o DBA deve fazer ao receber esse tipo de mensagem? Abraços, Fabricio

  • Anonymous
    October 18, 2010
    The comment has been removed

  • Anonymous
    October 18, 2010
    Bem, to meio na correria aqui e tem coisa ai que eu não entendo ainda, mas seguem algumas considerações.

  1. Nâo seria interante verificar se a conta de serviço está com a permissão de Lock Pages, pois caso a conta de serviço esteja sem ela, algum problema de pressão de memória no SO poderia fazer com que esse "roubasse" memória do SQL Server e causasse problemas?
  2. Lembro que havia um BUG do SQL x64 sobre trim de memória, onde das várias causas possíveis uma era que isso ocorria quando haviam cópias de arquivos grandes no servidor. Inclusive eu enfrentei esse problema na prática em um cliente. Não é referente exatamente ao post, mas talvez seja bom mencionar esse bug.

  • Anonymous
    October 18, 2010
    Vlad, O que eu sei do trim da memória é conhecido como “aggressive working set trimming"....isso acontecia entre o windows working set manager e o SQL Server...mas somente do WS 2003 para baixo... Se não tem memória suficiente para o sistema operacional e ele precisa,ele pega do SQL Server.No SP2 do SQL Server 2005,foi adicionado uma menssagem quando acontecia isso,peguei na net a msg: A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 1086400, committed (KB): 2160928, memory utilization: 50%. Fabricio....ai vai mais uma duvida...rsrsrss......se eu coloco em um ambiente 64 bits o lock pages in memory,mesmo assim se o SO precisa de memória,ele consegue "roubar" do sql server?? Abraços aos dois....

  • Anonymous
    October 18, 2010
    Fernando, realmente o ambiente era 2k3, faz tempo que vi esse problema. Nunca vi no 2k8. Quanto a pergunta que você fez, o ambiente era X64 e tinha "lock pages in memory" e mesmo assim o SO "roubava" a memória do SQL.

  • Anonymous
    October 18, 2010
    Pergunta: Qual o motivo do Stack Dump? Resposta:

  1. Assim como todo memory dump, é importante averiguar o que aconteceu no servidor. Assim como vocês analisaram da forma correta, houve paginação do SQL Server e esse é o grande vilão da história. 2009-05-05 15:43:56.01 Server Resource Monitor (0x13c43) Worker 0x0412C1E8 appears to be non-yielding on Node 0. Memory freed: 34152 KB. Approx CPU Used: kernel 171 ms, user 140 ms, Interval: 125093.
    2009-05-05 12:54:52.18 Server * *******************************************************************************
    2009-05-05 12:54:52.18 Server * BEGIN STACK DUMP:
    2009-05-05 12:54:52.18 Server * 05/05/08 12:54:52 spid 0
    2009-05-05 12:54:52.18 Server * Non-yielding Resource Monitor
    2009-05-05 12:54:52.18 Server * *******************************************************************************
    2009-06-10 09:13:53.44 Server * *******************************************************************************
    2009-06-10 09:13:53.44 Server * BEGIN STACK DUMP:
    2009-06-10 09:13:53.44 Server * 06/10/09 09:13:53 spid 0
    2009-06-10 09:13:53.44 Server * Non-yielding IOCP Listener
    2009-06-10 09:13:53.44 Server * *******************************************************************************
    Uma análise dos erros: Erro de "Non-yielding Resource Monitor" - Mensagem indica que a task do Resource Monitor parou de responder por um instante. Não é necessário analisar esse stack dump porque já sabemos sua causa.Erro de "Non-yielding IOCP Listener"  - Mensagem ultra-crítica e indica que o Listener do SQL Server parou de escutar na porta TCP/IP. Isso impede qualquer tráfego de rede e inclusive autenticação com o Domain Controller. Como já sabemos a causa (paginação de memória), não é necessário analisar esse stack dumpComo mencionado pelo Fernando, o problema é grave e observamos que ele afeta vários processos de sistema. Aqui, no caso, já sabemos que a causa do problema é a paginação de memória - ela é terrível e faz estragos! Do ponto de vista do suporte, quando abrimos o arquivo de Memory Dump, observamos que essas tarefas de sistema estão tentando acessar a memória virtual, mas houve uma troca de context para o Kernel do Sistema Operacional (SO). Esse é um indicativo que o SO estava paginando a memória do disco de volta para a memória RAM.
  • Anonymous
    October 18, 2010
    The comment has been removed
  • Anonymous
    October 18, 2010
    The comment has been removed
  • Anonymous
    October 18, 2010
    Conclusão sobre o Desafio Existem indícios de que existe paginação de memória. Por isso, recomendo seguir a proposta do Vlad:
  1. Nâo seria interante verificar se a conta de serviço está com a permissão de Lock Pages, pois caso a conta de serviço esteja sem ela, algum problema de pressão de memória no SO poderia fazer com que esse "roubasse" memória do SQL Server e causasse problemas?
  2. Lembro que havia um BUG do SQL x64 sobre trim de memória, onde das várias causas possíveis uma era que isso ocorria quando haviam cópias de arquivos grandes no servidor. Inclusive eu enfrentei esse problema na prática em um cliente. Não é referente exatamente ao post, mas talvez seja bom mencionar esse bug. Adicionando o seguinte: 3 - Verificar se existem processos consumindo grande quantidade de memória RAM, que causam a paginação. Pelo erro de login, é provável que esse seja um consumidor interno do SQL - uma DLL carregada no processo. 4 - Aplicar o Service Pack 2 do SQL 2005, que loga um erro no ERRORLOG se houver paginação do SQL Server. Obrigado aos que contribuíram! E fiquem à vontade para continuar postando dúvidas relacionadas a esse tipo de problema.

  • Anonymous
    October 19, 2010
    Fabricio,esse caso foi relacionado ao memtoleave em um ambiente 32 bits né?Em que situação eu posso ver uma situação dessa em um ambiente 64 bits? Cara,coloca mais artigos de desafio como esse....sensacional.... Parabéns pelo blog.... Abraço...!!!!

  • Anonymous
    October 20, 2010
    Olá Fabrício tudo bom? Postei um comentário há alguns dias atrás mais o mesmo não foi confirmado (acho que deu erro). Nós já passamos por este problema em clientes e verificamos que o KB citada resolvia o problema. Seria muito bom se você pudesse explicar um pouco sobre como analisar os Dumps. Tentei usar o www.microsoft.com/.../default.mspx mas não obtive sucesso. Abraço Demétrio Silva

  • Anonymous
    October 20, 2010
    Olá Fernando! Na plataforma 32-bits, a memória virtual (VirtualMemory) do processo é um recurso muito escasso e, por isso, a falha na criação de thread é um fato relativamente comum. Na plataforma 64-bits, esse recurso subiu de 2GB para 7TB, ou seja, fica muito difícil cair nesse cenário. Existem outros recursos como Desktop Memory, Paged Pool, Non-Paged Pool, VAD, Page File, Handles, etc. Nunca vi alguém chegar no limite desses recursos (sorte que o Mark Russinovich não lê em português, senão ele poderia me desmentir). Mas, teoricamente, esses recursos podem se esgotar e a criação de thread falharia. Abraços, Fabricio

  • Anonymous
    October 20, 2010
    Oi Demétrio! Internamente, a análise completa do dump é feita com auxílio do código-fonte do SQL Server. Por sorte, essa tarefa tem se tornado cada vez mais rara. Podemos conversar sobre os primeiros passos usados para analisar um Dump, que seriam: 1) Abrir o arquivo de dump, 2) Alinhar os símbolos, 3) Obter a stack trace. Antes de escrever um post sobre o assunto, vou procurar arquivos de DUMP para mostrar como exemplo. O que acha? Abraços, Fabricio

  • Anonymous
    October 21, 2010
    Acho excelente Fabrício. Ficaremos no aguardo. Grande abraço.