Início / dba / Perguntas / 115136
Accepted
Vaccano
Asked: 2015-09-16 11:53:39 +0800 CST

Alteração no tamanho do buffer?

  • 772

Eu tenho um banco de dados de produção que está enfrentando problemas de expectativa de vida da página (PLE) extremamente flutuantes. (Ele cai para zero em momentos aleatórios.)

Eu tenho pesquisado o problema do PLE e encontrei algo que parece apontar para um problema do VMWare, mas não tenho certeza se estou usando os dados corretamente. Parece que estou perdendo páginas de buffer/cache.

Estou usando esta consulta:

SELECT  COUNT(*) AS cached_pages_count, 
        CASE database_id
            WHEN 32767 THEN 'ResourceDb'
            ELSE DB_NAME(database_id)
        END AS database_name
FROM    sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id), database_id
ORDER BY cached_pages_count DESC;

(Encontrado aqui )

Estou totalizando os resultados (a contagem) antes e depois do travamento do meu PLE. Um exemplo é 1.097.820 antes e 131.394 depois. Portanto, pareço "perder" 966.426 páginas.

Meu palpite é que o hardware de todas as máquinas virtuais está sob estresse, então ele irá trocar aleatoriamente alguma memória do servidor por um tempo. (Isso é apenas um palpite.) Quando isso acontece, todas as páginas são perdidas, então o PLE despenca.

Então, estou usando a sys.dm_os_buffer_descriptorsvisão corretamente? Pelo que li, sempre mostra páginas de buffer/cache usadas. Portanto, se estiver vazio (ou significativamente reduzido), não tenho mais memória ou está vazio. (Eu adoraria uma maneira de confirmar esta conclusão.)

Ou há outra explicação de por que a contagem cai tanto?

As informações abaixo da linha foram adicionadas a partir dos comentários do OP

Nossos administradores de sistema gerenciam as VMs. Espero entender minha consulta antes de ir até eles com esses dados. O tempo das falhas do PLE parece aleatório do ponto de vista do banco de dados. (Sem reindexação ou outras coisas de alto desempenho acontecendo durante as falhas do PLE)

Eu fiz uma tonelada de trabalho para ver se estava relacionado à carga de trabalho. E embora haja uma consulta com baixo desempenho, não é suficiente para usar todo o cache. [Não há] nenhuma reconstrução ou outra atividade de usuário não rotineira no servidor quando as contagens de buffer diminuem. E mesmo que fosse, eu não veria isso sendo usado na minha consulta acima? (Ou seja, se fosse uma ação do SQL Server, as contagens não permaneceriam as mesmas, apenas com coisas diferentes?)

Não tenho acesso às configurações do VMWare. Eu esperava entender melhor minhas descobertas antes de envolver aqueles que entendem. O objetivo dessa pergunta era garantir que eu estava usando a exibição corretamente primeiro.

No final da cadeia de comentários:

Eu estava tentando dizer que o problema do PLE me levou à perda do problema das Buffer Pages. A consulta que eu estava usando para obter o PLE mostrava um PLE baixo porque as páginas estavam sendo perdidas. Então o que havia neles se foi. Foi uma leitura falsa porque a quantidade de memória foi reduzida.

Aqui está a minha @@Versão:

Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64) 
    Dec 28 2012 20:23:12 
    Copyright (c) Microsoft Corporation
    Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
sql-server sql-server-2012

2 respostas

  1. Best Answer

    P: Eu tenho um banco de dados de produção que está passando por problemas de expectativa de vida da página (PLE). (Ele cai para zero em momentos aleatórios.)

    Deixe-me perguntar qual é a saída de Select @@Version. Qual é o nível de SP e CU para o qual seu SQL Server está corrigido. A razão pela qual estou perguntando isso é porque houve um bug no SQL Server 2012 que forçou o PLE a despencar como o que você está observando. Este bug foi corrigido no SQL Server 2012 SP1 CU4 . Ou, para ficar mais seguro, recomendo que você aplique o SQL Server 2012 SP2 em vez de usar o CU4

    Às vezes é normal que o PLE flutue no sistema com alta atividade. Na verdade, é assim que o código PLE funciona no SQL Server. Mas o fato de cair para zero com bastante frequência me faz acreditar que você pode estar atingindo o bug que mencionei acima.

    De acordo com os detalhes da correção de bug da Microsoft

    Você pode ter um desempenho lento no SQL Server 2012. Ao verificar as ferramentas do SQL Server Performance Monitor, você verá o seguinte:

    •Um declínio rápido nos valores do contador de desempenho de expectativa de vida SQLServer:Buffer Manager\Page. Quando esse problema ocorre, o contador está próximo de 0.

    O PLE no sistema é a medida de quão volátil é o seu pool de buffers, também mede a quantidade de atividade de I/O em seu SQL Server. MSDN diz que

    Expectativa de vida da página - indica o número de segundos que uma página permanecerá no buffer pool sem referências

    Acredite em mim, esta definição está incompleta. Descreve-o na forma de tempo que não é uma definição completa. Sempre notei que é uma medida da atividade de E/S no servidor. Quanto maior a atividade de I/O, mais volátil seria o BPool, portanto PLE flutuante.

    P: Meu palpite é que o hardware de todas as máquinas virtuais está sobrecarregado, então ele irá trocar aleatoriamente alguma memória do servidor por um tempo.

    Se você acredita que esse é o caso e deseja que o SQL Server não seja vítima de tais problemas, certifique-se de que a conta de serviço do SQL Server tenha páginas bloqueadas no privilégio de memória (LPIM) . Isso não permitirá que o sistema operacional force a paginação do SQL Server em sua memória. Se a conta que executa o SQL Service for um sistema local por padrão, o SQL Server terá esse privilégio no SQL Server 2012.

    Observação:

    1. Esta é uma solução alternativa. A solução aqui seria descobrir o que está causando estresse na máquina VM. Você deveria consertar isso. Se você acha que Wmware Balooning é o problema. Você pode usar a ferramenta RAMMAP para rastrear a memória que é consumida por arquivos Locked Driver. Na ferramenta RAMMAP, se você vir o driver bloqueado consumindo muita memória, é um sinal de sobrecarga do VMware. Obtenha ajuda da equipe para configurar/desativar o balonismo para a máquina virtual na qual o SQL Server está sendo executado

    2. Antes de fornecer o LPIM, você deve certificar-se de que definiu o valor ideal para a memória máxima do servidor e deixou memória SUFICIENTE para o sistema operacional funcionar com eficiência.

    3. Se você não seguir os dois pontos acima e se o sistema operacional estiver sob forte pressão de memória devido ao LPIM, os processos do sistema operacional serão paginados porque não podem forçar o SQL Server a liberar memória (está bloqueado/não paginável devido ao LPIM) e, portanto, levando a uma tremenda lentidão de processos do SO.

    P: Então, estou usando a exibição sys.dm_os_buffer_descriptors corretamente? Pelo que li, sempre mostra páginas de buffer/cache usadas. Portanto, se estiver vazio (ou significativamente reduzido), não tenho mais memória ou está vazio. (Eu adoraria uma maneira de confirmar esta conclusão.)

    Os descritores de buffer já mencionados retornam informações sobre todas as páginas de dados que estão atualmente no buffer pool do SQL Server. Páginas de buffer IMHO are affected by I/O activity on server and thus indirectly related to PLE. Se houver solicitação para buscar uma grande quantidade de páginas do disco para a memória, é bem possível que o SQL Server descarregue páginas de dados para o disco se achar que precisa criar espaço no buffer pool para trazer as novas páginas na memória e, assim, diminuir a quantidade de página de dados presente na memória para um banco de dados específico.

    Portanto, o que você está vendo por meio de sys.dm_os_buffer_descriptors não está incorreto, mas gostaria que not suggestvocê usasse o descritor de buffer DMV para avaliar o PLE no servidor. Esta não seria uma abordagem correta.

    • 5

  2. Este foi um esforço de grupo e meu papel é principalmente como curador.

    Existem muitas razões pelas quais você pode estar vendo os resultados que está vendo.

    Zane ofereceu algumas causas potenciais quando comentou:

    A VM está sobrecarregada na memória? Outras atividades estão atingindo o pico durante esse período e, portanto, o Windows está tendo que recuperar a memória do servidor SQL? Isso acontece durante os tempos de carga alta? Que outro processo é executado nesta máquina?

    Tom V também ofereceu algumas causas potenciais em seu comentário:

    Você tem manutenção de índice naquele momento? Se você acha que é um problema de vmware, você tem acesso ao console do vmware? Em caso afirmativo, qual é o status do balonismo? O que MCTLSZ diz em esxtop?

    swasheck mencionou a importância de investigar a carga de trabalho também:

    Além das implicações de vmware que foram levantadas corretamente, você também não nos disse nada sobre sua carga de trabalho, o que significa que você está reconstruindo índices, gravando em páginas, etc.

    Como a pressão de VM/memória parece ser um provável suspeito, você deve fazer algumas perguntas básicas aos administradores de sistema.

    Algumas perguntas sugeridas a serem feitas de maneira não acusatória incluem:

    • Pergunte aos administradores do sistema se eles alocaram memória fixa ou dinâmica para sua VM. -Aaron Bertrand
    • Se eles estiverem aumentando ou superalocando [memória]. -Zane See More

    Também parece que você está confundindo PLE e o número de Buffer Pages na memória

    Várias pessoas mencionaram esse problema, incluindo swasheck inicialmente e Max Vernon , que disse:

    Como disse @swasheck, os números que você menciona em sua pergunta não são PLE. Eles são o número de páginas de buffer na memória. PLE é "Page Life Expectancy", que pode aumentar ou diminuir sem nenhuma alteração no número de páginas do buffer na memória. PLE é uma medida de quanto tempo a página média de dados permanecerá na memória. Eu vi servidores onde isso flutua de dezenas de milhares para 0 sem nenhuma perda no número de páginas alocadas na memória. Se o PLE estiver realmente baixo, isso indica um problema totalmente diferente do número de páginas do buffer diminuindo inesperadamente.

    Zane esclareceu o papel do PLE quando disse:

    Sim, o problema com o uso do PLE aqui é que ele não indica uma perda real na memória disponível para o Buffer Pool. Trata-se mais de medir a frequência com que as páginas são liberadas para dar lugar a novos dados.

    Melhores opções para verificar problemas de memória

    Max Vernon sugeriu usar a seguinte consulta:

    SELECT * FROM sys.dm_os_sys_memory ORDER BY system_memory_state_desc

    Kin também sugeriu que:

    System_health_session fornecerá uma imagem clara se for pressão de memória interna ou externa com notificação de pouca memória.

    Esse é um evento estendido que pode ser executado em segundo plano sem afetar o desempenho .

    • 4

relate perguntas