Justificando uma atualização de memória, leve 2

Question

Anteriormente, fiz uma pergunta sobre quais métricas devo medir (por exemplo, antes e depois) para justificar uma atualização de memória. Perfmon foi sugerido.

Gostaria de saber quais contadores de perfumes específicos eu deveria estar medindo. Até agora eu tenho:

PhysicalDisk/Avg. Disk Queue Length (for each drive)
PhysicalDisk/Avg. Disk Write Queue Length (for each drive)
PhysicalDisk/Avg. Disk Read Queue Length (for each drive)
Processor/Processor Time%
SQLServer:BufferManager/Buffer cache hit ratio

Quais outros eu devo usar?

    

Answer 1

Primeiro, sugiro ler meu responder sobre como funciona a memória do Windows . Depois disso, vamos falar sobre contadores. De uma perspectiva de monitoramento de desempenho puro, a memória do servidor e o desempenho do SQL Server não estão relacionados principalmente porque o SQL Server (se configurado corretamente) usa a capacidade de bloquear páginas na memória para substituir o esquema padrão de gerenciamento de memória do Windows. Olhando apenas para a memória, os contadores mencionados anteriormente estão OK:

SQL Memory Manager: Concessões de memória pendentes

SQL Buffer Manager: expecancy de vida da página

Objeto do Gerenciador de Buffer do SQL Server: taxa de acertos do cache de buffer

Eu também adicionaria

SQLServer: Gerenciador de memória: memória total do servidor (KB) - isso mostra o quanto o SQL Server está gerenciando.

SQLServer: Gerenciador de memória: memória de servidor de destino (KB) - isso mostra quanto o SQL Server acha que gostaria de ter com base no número de buffers reservados pelo SQL Server quando ele é iniciado pela primeira vez. Se o total for menor que o alvo, não é provável que uma RAM extra ajude. Se o alvo for maior, você pode se beneficiar de mais memória.

Veja também o que deve ser monitorado quanto ao desempenho de linha de base do SQL Server .

    

Answer 2

Esses provavelmente não são os melhores contadores. O problema com a E / S do disco é que ela não será útil porque a E / S do disco depende muito mais da otimização do banco de dados, a menos que o banco de dados inteiro esteja na memória. Operações como varreduras de tabelas e relatórios / scripts de carga sobrecarregarão sua memória. Uma carga pesada de E / S produzirá E / S no arquivo de log, independentemente da memória.

Esses contadores de disco não são os melhores para análise de disco - o tamanho da fila nem sempre é claro porque varia dependendo do layout do hardware. Por exemplo, 250 pode não ser um tamanho de fila ruim para o seu disco, mas talvez não se você tiver uma SAN de grande capacidade que possa lidar com muitas solicitações paralelas.

Eu prefiro ir com os fatores primários: Disco sobrecarregado, I / O leva mais tempo, segundos / leitura, segundos / fio - isso é não-subjetivo. Mais dados primários, como segundos / leitura, fornecem um número único, não dependente do hardware, e tempos de resposta mais baixos mostram o que você realmente está procurando.

Para memória, eu levaria:

• SQL Memory Manager: Concessões de memória pendentes
• SQL Buffer Manager: expecancy de vida da página

O último dá uma ideia de quão rápido as páginas estão saindo novamente. Você tem que ter certeza, porém, que alguém não está forçando isso - as varreduras de tabela são perfeitas para isso (basicamente, você sobrecarregará o cache com uma varredura de tabela, a menos que toda a tabela caiba na memória).