Articles

SQL: expectativa de vida da página

Posted by admin

sintomas: o SQL detectou uma queda na expectativa de vida da página, produzindo respostas mais lentas.

impacto: médio

as respostas SQL lentas degradarão a experiência do usuário, resultando em baixa eficiência das operações da sua organização.

comportamento esperado:

quanto mais uma página puder permanecer no pool de buffer e ser lida da memória, melhor será o desempenho do sistema. Recomendamos definir o valor limite em 300 segundos para cada 4 GB de memória buffer pool (BP).

possíveis causas de expectativa de vida de página baixa persistente (PLE)

baixa prioridade de energia da CPU: média
ação recomendada :
o uso continuamente alto associado ao PLE baixo pode indicar a necessidade de uma atualização da CPU ou a adição de vários processadores. Veja nossa explicação do uso da CPU aqui
alternativamente, uma alta taxa de uso da CPU pode indicar um aplicativo mal ajustado ou código SQL. Otimizar o aplicativo pode reduzir a utilização da CPU.

prioridade RAM insuficiente: Médio
revise a quantidade de RAM total alocada para SQL (enquanto ainda mantém RAM suficiente para as necessidades do sistema operacional). Compare a proporção de memória SQL com o tamanho do banco de dados – com base em nossa experiência, uma proporção de RAM total superior a 20% do maior banco de dados é ideal.
ação recomendada:
se possível, aloque mais memória para SQL ou adicione alternadamente RAM física ao servidor e aumente a alocação de memória SQL.

arquivo de página ocupado/prioridade lenta: baixa
verifique o que mais está sendo executado que pode estar diminuindo a velocidade de acesso ao disco. O pool de buffer troca as páginas para o disco quando o espaço de memória é necessário. Esse processo depende muito da eficiência das ações de leitura/gravação de dados no disco rígido e do nível de demanda.
ação recomendada:
para acelerar a E/S do disco e diminuir a latência, localize o arquivo de página na unidade disponível mais rápida (ou atualize para um hardware mais eficiente). Além disso, reduza a concorrência por esse recurso de outras operações. O aimbetter resource monitor fornece estatísticas abrangentes sobre espaço total em disco, espaço livre e atividade de arquivo de página.

prioridade incorreta de alocação do pool de Buffer: Baixo
no SQL Server, os dados são armazenados em páginas de 8 KB. Quando os dados são necessários para entrada / saída, a página é lida pela primeira vez a partir do disco e armazenada na memória. A área alocada é chamada de pool de Buffer. Uma vez que uma página é carregada no pool, todo o acesso subsequente é muito rápido e eficiente, enquanto a E/S do disco é relativamente lenta. O máximo de memória possível deve ser alocado para o pool de buffer, sem passar fome no sistema operacional.
ação recomendada:
aloque a proporção ideal de RAM física para BP, mas deixe RAM suficiente para operações de SO. Defina um valor na opção de memória máxima do servidor da página ‘Opções de memória do servidor’, que deixa memória suficiente para o próprio sistema operacional. Recomendamos torno de 4 GB, a menos que a quantidade total de RAM instalada

Possíveis causas ou transitória baixa Expectativa de Vida da Página (PLE)

Índice de falta ou danificado Prioridade: Alta
índices Ausentes significa que o SQL Server está sugerindo que a consulta poderia correr mais rápido, com um índice. 99% do tempo, a corrupção é disco ou driver de disco/firmware relacionado.
ação recomendada:
no caso de um índice ausente, consulte sua equipe de design do sistema.
em caso de índices corrompidos, consulte sua equipe de gerenciamento de armazenamento ou nossos especialistas em suporte para obter ajuda. Uma solução possível nos casos em que a corrupção está se repetindo é clonar o banco de dados em uma nova configuração de hardware.

problemas de codificação prioridade: baixa
talvez um resultado de problemas como planos de consulta ineficientes ou padrões de codificação inadequados.
ação recomendada:
inspecione o plano que o SQL estava usando, para determinar se era ideal.
investigue as consultas do banco de dados, para ver se as consultas de dados necessárias estão corrompidas ou incorretas.
investigue a codificação, então veja se a eficiência pode ser melhorada.

consultas saturando a prioridade do pool de Buffer: baixa
essas causas não persistem por longos períodos. As principais causas são:

  • a obtenção de grandes concessões de memória
  • deslocamento de um grande número de páginas de memória com novos
  • modificar muitas páginas, forçando-os a ser liberados para o disco
  • muitos concorrentes (ou muito grande) consultas

ação Recomendada :
nos casos em que estão ocorrendo novamente ou mostrando uma tendência a aumentar de magnitude (PLE inferior), investigue as outras causas possíveis abaixo.

DBCC CHECKDB prioridade de execução: baixo
CHECKDB é muito intensivo em recursos-provavelmente uma das coisas mais intensivas em recursos que o SQL Server executa. Introduzir este processo como uma carga adicional de IO em cima da carga normal do SQL Server significa que as cabeças de disco estarão se movendo constantemente.
ação recomendada :
sugerimos executar qualquer processo CHECKDB essencial em um momento de carga mínima do SQL Server ou, alternativamente, em cópias de backup dos bancos de dados offline.

o índice reconstrói a prioridade de execução: baixa
uma operação de reconstrução de índice sempre construirá um novo índice, o que significa que é necessário espaço extra para construir o novo índice antes de soltar o antigo; muitos recursos de CPU e E/S são necessários, o que pode sobrecarregar o sistema.
ação recomendada :
se ocorrer com frequência, pode ser corrigido por alterações no procedimento de indexação, por exemplo, alternando para uma estratégia na qual a fragmentação é analisada todas as noites e apenas os índices fragmentados são processados. Nossos consultores de equipe de suporte especializado estão disponíveis para análise e assistência.

Background

page Life expectation metric mede o número médio de segundos que as páginas ficam no pool de buffer. Está intimamente relacionado ao uso do arquivo de página-veja aqui.
para um desempenho ideal, os dados devem ser lidos da memória em vez do disco, o que é muito mais lento. O SQL consegue isso utilizando páginas de memória que armazenam os dados acessados Mais recentemente. Uma área reservada de memória (o pool de buffer) está disponível para o armazenamento dessas páginas. Quando o pool de buffer está cheio e o SQL requer novo espaço, o servidor troca a Página mais antiga para o arquivo de página no disco e lê os novos dados. Aumentos no número de trocas entre memória e disco afetam diretamente o desempenho.
níveis baixos sustentados de PLE é um indicador confiável da pressão de memória do SQL Server. Esta pressão pode ser um resultado de alta demanda, ou de ineficiente organização de dados, tanto físico e lógico
Nós recomendamos a definição do limiar de 300 segundos para cada 4 GB de Pool de Buffer (PB) de memória no servidor, o que significa que o servidor deve manter qualquer página na memória (depois de um processo de referências a página) no pool de buffer para no mínimo 5 minutos antes de ele é liberado para o disco. Se o pool de buffer estiver liberando páginas em menos de 300 segundos, provavelmente há um problema.
quanto mais memória seu servidor tiver, mais leituras e gravações de disco em cache ele poderá executar. A falta de memória do sistema pode causar leituras e gravações de disco não armazenadas em cache. Adicionar memória ao seu servidor pode ajudar a diminuir o acesso ao disco físico.

Related Post

Leave A Comment