desempenho SQL, como medir exatamente os gargalos

Question

Ontem, eu (programador) e um de meus colegas de trabalho do nosso departamento de hospedagem iniciaram uma série de testes para solucionar problemas de desempenho em nossos sites. Estamos executando um servidor com o Windows Server 2008 com 8GB de RAM. Vamos atualizar nosso servidor com um RAM adicional de 8 GB porque nossos clientes estão tendo um desempenho lento do backend (Sitecore). Acreditamos que nossos problemas de desempenho estão relacionados a ter muitos bancos de dados em nosso servidor. Tivemos uma rápida olhada nos contadores de desempenho no servidor que estamos testando, mas nosso servidor de teste é totalmente diferente do nosso servidor ativo. Isolamos alguns sites no servidor de testes e iniciamos alguns testes de estresse / banco de dados no servidor e tentamos medir com os contadores com os quais não temos experiência. Como podemos resolver o problema em nosso servidor ao vivo usando contadores de desempenho? Existe algum bom guia sobre como lidar com esse tipo de problema de desempenho? Qualquer conselho seria muito apreciado!

    

Answer 1

Não acho que os contadores de desempenho forneçam uma resposta útil para isso, pois eles só costumam dizer a você com frequência que certas coisas aconteceram ou que tipo de taxa de transferência você está obtendo, mas você já sabe que a taxa de transferência não é boa.

Eu dei uma olhada nos contadores de desempenho disponíveis em nosso MS SQL Server e nada me parece particularmente útil para isso. Você pode experimentar alguns dos contadores na categoria SQLServer: Wait Statistics para obter algumas indicações.

No entanto, gostaria de começar com os suspeitos do costume:

1. Com frequência, os afunilamentos de desempenho com sites da Web com backup de banco de dados estão conectados a consultas de banco de dados lentas. Isso geralmente é causado por índices ausentes e design de consulta incorreto. Dependendo da sua versão do SQL, você deve ser capaz de consultar o Google para identificar consultas lentas.
2. Se você estiver executando o MySQL como seu banco de dados, deverá analisar regularmente o log de consultas lentas.
3. Também para o MySQL, inspecione as variáveis de integridade do servidor, especialmente as seleções de junção completa.
4. Se for possível, separe o servidor de banco de dados do servidor da web. A troca de contexto constante também não é boa para o desempenho.

Answer 2

Em um trabalho anterior, fui encarregado de encontrar alguns problemas de desempenho e aconselhar um caminho para correção. Eu sempre começo a olhar para alguns contadores básicos no perfmon.

%Disk Time
%Idle Time
Avg Disk Queue Length
Avg Disk sec/Transfer
Pages/sec
% Processor Time

Também tentarei isolar algumas das páginas lentas do aplicativo e revisar suas consultas. Às vezes, páginas de impacto pesadas, como a página principal, podem ter consultas lentas que retardarão outras consultas de desempenho adequado. Uma vez que eu tenha rastreado algumas das consultas, normalmente vou executá-las no estúdio de gerenciamento e ver seu plano de consulta para pontos problemáticos, como um índice ausente ou impróprio. Isso é bem básico no final. Isso também foi fácil para mim, pois era um aplicativo SAAS em que muitos clientes se conectavam aos servidores salvos, usando o mesmo software.

A lentidão pode estar vindo do fato de você estar atingindo um ponto de inflexão natural em que o tráfego da web e o servidor de banco de dados são demais para uma caixa. Mas antes de você ir despejando US $ 5.000 em um novo servidor de banco de dados, dê uma espiada nos dados do perfmon e veja se algo ainda não está se destacando. No meu caso, muito disco IO em uma matriz de armazenamento anexado direto foi o problema. Adicionando fusos adicionais era uma solução possível. Além de adicionar mais memória para permitir mais cache e descarregar os arquivos de log em uma matriz RAID diferente na máquina. Nesse caso, também a camada da Web não estava no servidor de banco de dados, então esse não era o problema para mim.