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

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

  • Comments 15

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
http://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!

  • 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....!!!!!

  • 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

  • 1 - Olha...para gerar o Dump,e com essas menssagens ainda,é caso critico,é o nivel máximo de gravidade.....rs...

    2 - Eu sei que o resource monitor é o responsavel por fazer o monitoramento de recursos do SO,caso aconteça algo no SO,o resource monitor é responsavel por avisar ao memory broker de que o SO precisa de memória,ai cabe ao memory broker "ordernar" para cada clerk limpar a sua area de memória,inclusive os clerks do CLR(MEMORYCLERK_SQLCLR e MEMORYCLERK_SQLCLRASSEMBLY),tem  .Duvida,o lazy writer parou de executar?E sobre a parte do Non-yielding IOCP Listener  esta correto o que eu disse?Tem haver de a memória não aguentar as solicitações,fazendo o disco "sofrer"?

    3 - Fiquei curioso sobre o ponto de diferença entre thread e worker thread..rsrsrs....ja prepara esse post...rsrsrs....

    Eu a partir do momento que recebo essa menssagem se eu não tenho support premier,eu tenho que me virar,mas se tivesse o support eu entraria em contato no momento que acontecesse.....

    Abraços

  • 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.

  • 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....

  • 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.

  • 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 dump

    Como 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.

  • Pergunta: Qual a relação entre o Lazy Writer e as mensagens de erro do SQLCLR?

    Resposta:

    A questão toda está relacionada com a tarefa de sistema Resource Monitor, que detectou a necessidade de liberar memória de volta ao Sistema Operacional. Essa tarefa é responsável por fazer o broadcast da mensagem "Low memory" para todos os componentes do SQL Server (Memory Clerks). Entre esses componentes, inclui o CLR, Buffer Pool, Procedure Cache.

    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.

    As mensages são os primeiros indícios de que há falta de memória por conta de um "consumidor de memória" agressivo. Existem dois tipos:

    • Consumidores internos - CLR, Lock Manager, Extended Stored Procedures, e qualquer coisa que roda dentro do SQL Server. Qualquer DLL que roda dentro do processo do SQL Server.
    • Consumidores externos - Qualquer processo que roda externo ao SQL Server, como os softwares de anti-virus, monitoração, etc.

    Explicando um pouco as mensagens:

    • Erro "LazyWriter: warning, no free buffers found" - Indica que o Resource Monitor avisou o LazyWriter para rodar e liberar memória, mas não foi possível liberar nada. Isso costumava acontecer nos tempos antigos do DBCC PINTABLE. Atualmente, há poucas razões para isso ocorrer e normalmente está ligado a paginação do SQL Server para disco.
    • Warning "AppDomain xx (SQLCLR.dbo[runtime].xx) is marked for unload due to memory pressure" - Esse erro é simples: SQL Server precisa de memória e está liberando tudo que pode. Pode ser considerado um warning, mas reforça a idéia de que exista um "consumidor de memória".

  • Pergunta: Qual o impacto do erro de Logon?

    Resposta: Ninguém se loga!

    Aproveito para colocar uma dica do mundo 32-bits. Sempre que houver uma mensagem assim:

    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]

    Erros de "spawn a thread" significam que o SQL Server não conseguiu criar uma thread! Isso é um cenário desesperador, porque a chance de ocorrer é muito baixa. Em praticamente todos os 99% dos casos [sem referência], o problema é falta de memória VIRTUAL. Isso acontece quando algum "consumidor de memória interno" reserva o espaço de memória sem utilizá-la.

    Os principais culpados são DLL associadas a Linked Server, Extended Stored Procedure e também CLR!!!

    Se esse erro ocorre frequentemente, então a única solução para aliviar o problema é usar o parâmetro de inicialização -g 384 ou -g 512. Se isso não resolver, então deve-se migrar para a plataforma 64-bits.

  • 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.

  • 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...!!!!

  • 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

  • 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

  • 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

  • Acho excelente Fabrício. Ficaremos no aguardo.

    Grande abraço.

Page 1 of 1 (15 items)
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post