Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Cache de buffer:o que é e como isso afeta o desempenho do banco de dados?




No SQL Server, o cache de buffer é a memória que permite consultar rapidamente os dados acessados ​​com frequência. Quando os dados são gravados ou lidos em um banco de dados SQL Server, o gerenciador de buffers os copia no cache de buffer (também conhecido como pool de buffers). Quando está cheio, as páginas de dados mais antigas ou usadas com menos frequência são movidas para o disco rígido.

Por que preciso monitorar o cache do buffer?


O uso de memória pode ter um impacto significativo no desempenho. Quando não há memória suficiente, as páginas de dados são removidas frequentemente do cache de buffer. Isso torna as consultas mais lentas porque o SQL Server precisa ir ao disco para localizar a página de dados, restaurá-la no cache do buffer e ler a página antes que ela possa retornar os resultados da consulta.

Há muitas razões pelas quais as consultas começam a ser executadas lentamente. Mas se você quiser descartar problemas de memória, veja o que está acontecendo dentro do cache do buffer. Uma olhada dentro dele identificará qual banco de dados, tabela ou índice está sobrecarregando a memória e pressionando o buffer.

Para ver qual banco de dados consome mais memória, use a consulta:
SELECT
CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE db_name(database_id)
END AS database_name, COUNT(1)/128 AS megabytes_in_cache
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id) ,database_id
ORDER BY megabytes_in_cache DESC;

Para identificar a tabela ou índice que consome mais memória, execute esta consulta no banco de dados que deseja inspecionar:
SELECT COUNT(1)/128 AS megabytes_in_cache
,name ,index_id
FROM sys.dm_os_buffer_descriptors AS bd
INNER JOIN
(
SELECT object_name(object_id) AS name
,index_id ,allocation_unit_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p
ON au.container_id = p.hobt_id
AND (au.type = 1 OR au.type = 3)
UNION ALL
SELECT object_name(object_id) AS name
,index_id, allocation_unit_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p
ON au.container_id = p.partition_id
AND au.type = 2
) AS obj
ON bd.allocation_unit_id = obj.allocation_unit_id
WHERE database_id = DB_ID()
GROUP BY name, index_id
ORDER BY megabytes_in_cache DESC;

Gerenciar memória com métricas


Embora seja útil verificar o uso excessivo de memória em bancos de dados e índices, rastrear métricas de cache de buffer é realmente a melhor maneira de identificar e resolver problemas de desempenho causados ​​por pressão interna na memória.

Aqui estão as cinco principais métricas a serem monitoradas para melhorar os problemas de desempenho relacionados à memória:

1. Taxa de acertos do cache de buffer

  • Esta métrica mostra como o SQL Server utiliza o cache de buffer
  • A taxa de acertos identifica a porcentagem de solicitações de página que foram concluídas por páginas de dados do cache de buffer em relação a todas as solicitações de página de dados
  • As páginas que não são encontradas no cache do buffer são lidas do disco, o que é muito mais lento
  • A proporção ideal de cache de buffer é 100 (ou seja, o SQL Server lê todas as páginas do cache de buffer e nenhuma do disco)
  • O valor de cache de buffer recomendado é maior que 90

2. Expectativa de vida da página (PLE)

  • A expectativa de vida da página mede por quanto tempo (em segundos) uma página de dados permanece no cache do buffer
  • Quanto maior o PLE, maior a chance de o SQL Server ler as páginas do cache de buffer e não precisar ir para o disco
  • Se não houver memória suficiente, as páginas de dados serão liberadas do cache do buffer com mais frequência para liberar espaço para novas páginas
  • Historicamente, quando os sistemas tinham muito menos memória do que agora, um valor "normal" de PLE era de 300 segundos
  • Hoje, uma fórmula é usada para determinar o PLE “bom”:expectativa de vida da página =300 segundos para cada 4 GB de RAM em seu servidor
  • O PLE deve permanecer estável se monitorado ao longo do tempo
  • As diminuições rápidas e frequentes indicam problemas de memória
  • Uma queda de mais de 50% deve ser investigada imediatamente

3. Leituras de página/s (nível do servidor)

  • Esta métrica mostra quantas leituras físicas (ou seja, leituras do disco) ocorreram em um segundo em todos os bancos de dados em uma instância
  • As leituras físicas são caras e lentas
  • Diminua as leituras físicas usando um cache de dados maior, índices inteligentes e consultas mais eficientes ou alterando o design do banco de dados
  • O valor recomendado é inferior a 90
  • Um valor maior que 90 indica memória insuficiente e problemas de indexação

4. Gravações de página/seg

  • Esta métrica mostra o número de vezes que as páginas foram gravadas no disco no nível do servidor em um segundo
  • O valor recomendado é inferior a 90

5. Entrada/seg de páginas e saída/seg de páginas (contadores de memória)

  • Entrada de páginas/s é o número de páginas trazidas do disco a cada segundo
  • Saída de páginas/s é o número de páginas gravadas no disco a cada segundo para liberar espaço no cache do buffer
  • Páginas/s é a soma das páginas de entrada/s e das páginas de saída/s
  • Se o valor de páginas/s for consistentemente superior a 50, será necessária uma investigação adicional

Um cache de buffer íntegro é um componente importante para otimizar a velocidade de consulta do SQL Server. Embora os problemas de memória sejam apenas um dos vários fatores que podem retardar as respostas de consulta, eles são bastante fáceis de identificar e resolver. O rastreamento dessas cinco métricas principais pode ajudá-lo a manter as páginas de dados no pool de buffers por mais tempo para que o SQL Server não precise perder tempo pesquisando o disco antes de retornar os resultados da consulta.