Justificando um upgrade de memória

Question

Meu empregador tem mais de mil servidores (executando o SQL Server 2005 x64 e alguns outros aplicativos) em todo o país. E na minha opinião, eles são todos maciçamente desprovidos do que precisam fazer.

Especificamente, sinto que os servidores simplesmente não têm RAM suficiente para a quantidade de volume que as máquinas são solicitadas a fazer. Todos os servidores atualmente possuem 6 GB de RAM. Os usuários estão sempre reclamando de desempenho (principalmente porque, immo, o servidor mergulha no arquivo de paginação com bastante frequência).

Eu finalmente convencei os poderes de tentar pelo menos uma atualização de memória em uma caixa e ver os resultados. No entanto, eles querem medições antes e depois, para que possam ver que a despesa será justificada.

Minha pergunta é quais métricas devo coletar para ver se o desempenho realmente melhora na caixa? Eu sou um dev, então não tenho certeza de como e o que coletar (eu tenho um conhecimento passageiro de Perfmon).

EDIT: Eu acho que estou procurando contadores específicos para testar.

    

Answer 1

Eu recomendaria que você fizesse testes de carga na caixa antes e depois da atualização de memória por meio do aplicativo. Simule a carga que causa a degradação no desempenho do ponto de vista do usuário e, em seguida, mostre as melhorias após o upgrade da memória (algo como o jmeter poderia fazer isso em um aplicativo da Web). Se você não pode fazer isso com o teste de carga do aplicativo, talvez você possa simular as consultas.

Então, ao fazer isso, você também pode executar os contadores que Farseeker recomenda. A razão pela qual eu acho que você deveria fazer isso através do front end é que eles são pessoas de negócios, e eles provavelmente não obterão toda a explicação do arquivo de paginação ou tempo de consulta etc. Eles devem entender o tempo de resposta do aplicativo, pois é isso que todos estão procurando para melhorar.

No entanto, se os testes custarem mais do que a própria memória (fazendo os planos de teste, configurando servidores para gerar a carga, etc), talvez você deva pedir que eles confiem em seu julgamento ou façam os melhores testes possíveis.

    

Answer 2

Verificar se você precisa de uma atualização de memória geralmente é bem simples. Alguns contadores perfmon dirão quantas vezes o SO está mergulhando no arquivo de paginação, assim como a utilização da memória, páginas, etc. Além disso, como é o SQL Server, você também pode usar o profiler para ver quantas sendo feito para determinadas consultas. Se a utilização da memória é qualquer coisa < 90%, então o servidor SQL não está configurado de forma otimizada. Não use o gerenciador de tarefas para isso, pois a coluna de memória "livre" inclui a quantidade alocada para pré-busca.

Você precisa ser capaz de convencê-los (e a si mesmo) de que isso é necessário por meio dessas métricas antes de você se incomodar em fazer antes / depois dos testes. Os testes antes / depois costumam fazer o backup de sua prova original. E se suas métricas não sugerirem que você precisa de mais memória RAM, isso economiza o ovo em seu rosto.

No entanto, para consultas antes / depois, usaria uma consulta comum (não muito simples, algo real), jogue-a no SQL Management Studio, ative o plano de execução (para ter certeza de que está executando mesmo plano a cada vez e, assim, você obtém resultados válidos) e o tempo que levam.

    

Answer 3

Também pode valer a pena reunir algumas estatísticas de perfmon para taxas de páginas, filas de disco, etc.

    

Answer 4

Se você prosseguir com a atualização, lembre-se de que nem toda a RAM é produzida com perfeição. Mesmo o ECC ram pode ser produzido com defeitos, embora defeitos sérios sejam mais raros. Se possível, faça uma verificação inicial da memória usando algo como o Memtest86 + antes de instalá-lo nos servidores. Melhor ainda se você puder executar o mesmo teste após a instalação, mas isso significa mais tempo de inatividade.

Seu cliente não ficará satisfeito se sua "atualização" levar a servidores instáveis.

    

Answer 5

Os contadores do monitor de desempenho são todos bons e bons, mas nem sempre contam toda a história. Acho que você também precisa avaliar isso em termos de alterações na percepção do desempenho do aplicativo pelo usuário.

Você tem um "SLA" que define o desempenho aceitável para este aplicativo em determinadas tarefas / cenários (e, se não, por que não?).

Ou você verá uma melhoria na capacidade de resposta do aplicativo que leva a uma queda quantificável nas reclamações de desempenho, e / ou o aplicativo está realizando um trabalho melhor para atender aos requisitos de SLA ou não.

Os serviços foram "ajustados" corretamente para o sistema? Pode ser que o processo SQL esteja usando muita memória, como gosta de fazer, e não tenha um limite definido sobre o que pode usar e isso está afetando o desempenho de outros componentes fora da parte do aplicativo baseada em SQL ?

Você já estabeleceu que isso não é um gargalo no disco ou na rede?