Como posso acelerar as consultas do SQL Server no Amazon EC2?

Question

Nossas consultas SQL às vezes demoram muito. Nós temos uma configuração do Windows Server 2003 / SQL Server 2005. Já criamos índices em todos os lugares possíveis. Podemos obter discos mais rápidos? Alguma idéia de alguém?

    

Answer 1

A linha atual de pensamento (a partir de julho de 2011) é que o melhor desempenho no EC2 é por REALIZANDO os discos efêmeros (quanto maior o seu exemplo, mais existem). É melhor que você tenha backups caso opte por fazer isso, pois qualquer tipo de falha no host significa que seus dados podem e irão desaparecer.

Como Tom sugere, você pode volumes de RAID EBS: o desempenho não é tão bom quanto você tem que sair para a rede, mas você diminuirá sua busca à medida que aumenta o número de eixos que podem procurar em paralelo. Aqui estão alguns bons benchmarks .

Há outras coisas a serem consideradas, como tamanhos de instância que provavelmente você é a menor contenção e os tamanhos do volume do EBS que maximizam seu desempenho . Certifique-se de "aquecer" seus volumes antes de usá-los também, pois há uma penalidade na primeira gravação em discos efêmeros e uma penalidade de leitura inicial no EBS.

Finalmente, você não tem muito mais do que um especialista em SQL Server do que Brent Ozar, então leia e entenda seu post sobre o tema . Isso levou a uma conversa no fórum da AWS que fala sobre as métricas de desempenho relativas para as quais você pode otimizar.

    

Answer 2

Pegue um monte de volumes do EBS e agrupe-os em um array RAID10. Em seguida, coloque seus dados nessa matriz e, teoricamente, você deve obter melhor desempenho .

Funciona no Linux. Não tenho ideia de como você faria isso no Windows, mas essa é a teoria.

    

Answer 3

Recomendo, como acontece com qualquer problema de desempenho, medir e identificar seu gargalo. Use uma metodologia bem comprovada, como esperas e filas . Somente depois de identificar a causa do problema, você pode propor e testar soluções. Parece tão óbvio, mas tão poucos fazem isso ...

Invadir seu EBS ou volumes efêmeros é uma solução se, e somente se, o problema for identificado como causado por alto IO que não pode ser endereçado de outra maneira. Desde que você implante no EC2, sua solução deve ser projetada para se encaixar em uma instância do EC2 sem derramamento do buffer pool (sem a necessidade de ler do disco) e o único IO deve ser o aquecimento inicial, atualizações no ponto de controle e, é claro , liberar log. Se você acha que precisa de mais IO do que isso, então sua melhor abordagem é analisar a estrutura do banco de dados e o código do aplicativo e colocá-los em seu host de destino, você obterá muito mais milhagem do que qualquer outra coisa que puder fazer . O que o que significa exatamente é, novamente, completamente dependente de sua aplicação e seus resultados de investigação.