SQL Express 2008 R2 na instância do Amazon EC2: toneladas de memória livre, baixo desempenho

Question

O antigo SQL Express 2005 estava sendo executado em um servidor Dell de CPU Xeon de baixo custo, discos RAID 5 7200, 2 GB de RAM (SBS 2003).

Eu não fiz nenhuma medida de linha de base no servidor físico antigo, mas o aplicativo Web é usado por meia dúzia de pessoas (talvez 2 simultaneamente), então imaginei "quão ruim pode ser uma instância do Amazon EC2?".

É bastante horrível: uma diferença de 8 segundos de tempo de carregamento em uma tela.

Primeiro de tudo, eu não sou um guru de SQL, mas aqui está o que eu tentei:

• Possuía uma Instância pequena, agora executando uma instância do Windows 2008 de 32 bits R2 com suporte para EBS do c1.medium (High Cpu Medium) executando o IIS 7.5 e o SQL Express 2008 R2. Nenhuma melhora perceptível.

• Arquivo de página alterado de fixo 256 para automático.

• Configure um Espelhamento listrado de dentro do Gerenciamento de disco com dois volumes EBS de 1 GB conectados. O banco de dados e o log de transações movidos deixaram tudo o que havia no volume de inicialização do EBS. Nenhuma mudança perceptível.

• Olhou para a memória, ~ 1000 MB de memória física livre (1,7 GB no total). Instância SQL alterada para usar um mínimo de 1024 RAM; servidor reiniciado, nenhuma mudança no uso da memória. SQL ainda usando apenas ~ 28MB de RAM (!).

Estou pensando: esse banco de dados é minúsculo (28MB), por que a coisa toda não está armazenada em cache na RAM? Certamente isso aceleraria o desempenho. O log de transação é de 241 MB. Parece meio grande em comparação - isso não foi confirmado? É uma causa de degradação do desempenho? Lembro-me de algo sobre Modelos de Recuperação e tamanhos de registro em algum lugar em minhas viagens, mas não positivo.

Outra coisa: o servidor antigo estava executando o SQL Express 2005. Não tenho certeza se isso tem algum impacto, mas eu tentei mudar o nível de compatibilidade do SQL 2000 para 2008, mas isso não teve efeito.

De qualquer forma, o que mais posso experimentar aqui? Parece ridículo lançar mais hardware virtual nessa coisa. Eu sei que o I / O será difícil nos volumes do EBS, mas com certeza outros estão executando com sucesso pequenos aplicativos .NET / SQL em instâncias com preços razoáveis?

    

Answer 1

1. Sempre que eu atualizo bancos de dados, e faço isso há pelo menos doze anos, entre as primeiras coisas que faço depois de trazer o banco de dados de volta é reindexar todas as tabelas. Eu faço isso antes de deixar alguém usar o banco de dados. A reindexação é simples e só deve levar alguns segundos para reindexar 28 MB de dados em algo mais rápido que um laptop a partir de 2005.

2. Verifique se o banco de dados está definido como AUTOCLOSE = FALSE. Alguns ambientes usam como padrão TRUE, o que é errado para qualquer servidor de produção.

3. Como cmenke diz, a menos que você esteja usando uma estratégia de recuperação point-in-time, você deve configurar seu banco de dados para o modo de recuperação SIMPLE. O banco de dados foi definido para o modo de recuperação SIMPLE no servidor SBS?

4. O banco de dados no EC2 tem a mesma indexação que o banco de dados antigo? Você não mencionou como moveu seus dados, portanto, não sabemos se fez um backup e uma restauração, usou o Assistente para Cópia de Banco de Dados ou escreveu seus próprios pacotes do SSIS. Alguns métodos de movimentação de bancos de dados não preservam seus índices. Para qualquer futuro leitor desta resposta que esteja tentando mover bancos de dados entre servidores, você deve sempre tentar usar BACKUP / RESTORE ou copiar os arquivos MDF e LDF. Usando SSIS / DTS para todos, mas os bancos de dados mais triviais vão deixá-lo louco.

5. Se o banco de dados ainda estiver lento, inicie o SQL Profiler (no servidor, não na área de trabalho) e capture um pouco de tráfego. O problema é uma instrução SQL grande e lenta ou muitas e muitas pequenas instruções SQL? Quantas instruções SQL são emitidas pela primeira página?

Lembre-se de que você já fez várias alterações no SQL Server e não viu nenhuma mudança de comportamento. Talvez o problema esteja em outro lugar. A sua página da Web está interagindo com sua configuração do AD de uma maneira inesperada? Alguma coisa está falhando na página da Web sem mostrar nenhum erro? A página da Web está procurando algo na configuração antiga do SBS que não foi migrada para o EC2? Se você tiver o código e algumas opções de desenvolvimento, eu daria uma olhada nesse código.

    

Answer 2

A resposta é que o EBS é muito lento para o SQL Server.

Eu fiz testes extensivos. Para SQL lê o EBS é muito ruim. Para gravações SQL, é tão lento que nunca deve (nunca) ser usado.

Existem novos volumes do EBS com IOPS dedicados. Esse é o único caminho.

Configure dois volumes do EBS: um para ldf, um para mdf.

Ajuste IOPS até obter um bom desempenho.

Coloque tempdb no armazenamento de instância local.

    

Answer 3

Parece que a maioria do seu banco de dados é, na verdade, armazenada em cache na RAM. Você pode usar o contador da taxa de acerto do cache do Buffer: BufferManager BufferManager no perfmon para ver qual porcentagem de suas consultas está atingindo o cache em vez do disco. Quanto maior, melhor.

Eu também sugiro verificar seu disco e uso da CPU, sua lentidão pode não estar relacionada à RAM.

    

Answer 4

O enorme log de transações comparado ao tamanho do banco de dados é interessante. Eu não tenho certeza se é um problema real, mas você pode tentar se livrar dele, fazendo o seguinte: Verifique se o modelo de recuperação para o banco de dados está definido como "simples" (não "full"!), Então backup o banco de dados para um arquivo. Isso deve acionar um ponto de verificação e permitir que o SQL Server trunque o log.