A expectativa de vida útil da página do SQL Server 2012 é redefinida para 0 após cerca de 50 dias


12

Percebi um comportamento estranho em um cluster de alta disponibilidade de 2 servidores e esperava que alguém pudesse confirmar minha suspeita ou talvez oferecer alguma outra explicação ... Aqui está minha configuração:

  • Uma instalação do SQL 2012 SP1 com 2 servidores
  • O SQL AlwaysOn HA foi ativado para alguns bancos de dados
  • CPUs são 2.4GHz, 4 núcleos
  • RAM é de 34 GB (é uma instância da AWS, daí o número ímpar)
  • A utilização de recursos é relativamente baixa - cada servidor tem mais de 14 GB de memória livre e o SQL não tem limite de quanta memória usar
  • O tempo de acesso ao disco é bom - raramente ultrapassando 15ms / leitura ou gravação
  • Os bancos de dados não são grandes - 1 GB, 1,5 GB, 7,5 GB
  • O processo do servidor SQL está usando bytes particulares de 16 GB, conjunto de trabalho de 15 GB

No geral, nenhum problema de recurso é observado. Agora, a parte estranha. O SQL não é reiniciado (o processo está em execução há quase 6 meses), mas parece que a cada ~ 50 dias, o contador Page Life Expectancy cai para (quase) 0. Até esse ponto, ele sobe continuamente, sem quedas. Aqui está um gráfico de desempenho:

insira a descrição da imagem aqui

Quando olho para os dados do contador (não tenho o número exato, apenas uma agregação horária), parece que o valor do contador PLE atingiu cerca de 4.295.000 s (aproximadamente 50 dias) todas as vezes (pelo menos toda vez que tenho dados).

Minha teoria maluca é que o número PLE é mantido em milissegundos como um int longo sem sinal (que tem um limite de 4.294.967.295) e, aos 49,71 dias, ele é redefinido, por design ou por causa de um bug. Isso explicaria o comportamento dos dois servidores e o padrão idêntico que eles têm. Ou poderia ser algo totalmente diferente e simplesmente não estou fazendo nenhum sentido. :)

Alguém viu algo assim ou pode explicar esse comportamento?

PS Eu vi este post, mas meu caso parece um pouco diferente.

PPS Este é um repost - eu originalmente o publiquei aqui , mas foi aconselhado que o público aqui seja mais apropriado.

Obrigado!


Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .
Paul White 9

Respostas:


3

Eu já vi esse comportamento em um site cliente executando o SQL2012 SP1. As especificidades aqui foram NUMA e PLE demonstrando um padrão de 'dente de serra', mas em um ciclo horário.

Alguns tópicos no SQLServerCentral discutiram sobre isso:

http://www.sqlservercentral.com/Forums/Topic1415833-2799-1.aspx http://www.sqlservercentral.com/Forums/Topic1424826-2799-1.aspx

o resultado final é que a aplicação do SP1 CU4 pareceu resolver o problema.

CU4 contém a correção de aparência inocente Está disponível uma atualização para o Gerenciamento de memória do SQL Server 2012 KB2845380

Vale a pena tentar?


Obrigado por postar isso (desculpe pela resposta atrasada, por algum motivo nunca recebi uma notificação de sua postagem). Dei uma olhada nos links - eles são um pouco parecidos, então tentarei enganar a configuração no controle de qualidade, aplicar o CU4 (ou provavelmente até ir direto para o SP2) e verificar novamente. Com o ritmo que vejo (a cada 50 dias), levará um tempo até que eu possa confirmar, mas voltarei a postar quando tiver resultados. Aliás, meus padrões ainda se mantêm - subida constante por ~ 50 dias, queda acentuada para ~ 0 e subida novamente - total de 4 desde que o serviço foi iniciado em dezembro.
CRCerr0r

Atualização ... Confirmei isso em nosso ambiente de controle de qualidade. As estatísticas que obtive de lá são: Total de dias entre as redefinições - 49,71 (+/- 1 minuto); O valor máximo de PLE atingiu - 4.294.961 (em amostras de 1 minuto, portanto, poderia ter sido um pouco maior). Isso praticamente confirma as observações da produção. Vou aplicar CU4 e relatório de volta no ~ 50 dias ... :)
CRCerr0r

1
Alguma novidade sobre isso?
Michael Green
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.