Desempenho de disco rígido muito lento

Question

Hoje eu estava tentando executar uma consulta de longa duração (mas altamente otimizada) em um servidor da nossa empresa. Eu executei a mesma consulta nos mesmos dados em meu computador doméstico (disco rígido de 5400 rpm) e demorou cerca de 40 minutos. O servidor é cerca de 10 vezes mais lento, talvez ainda em execução! O servidor faz cerca de 30 inserções / segundo, meu computador de casa 300 inserções / segundo.

Como a carga da CPU é muito baixa (3%), a memória é abundante e a rede não é usada, pois a consulta é executada localmente. Suspeito que a E / S do disco seja o gargalo. No meu computador de casa (que tem melhor poder de CPU), dois núcleos estavam quase totalmente carregados.

A configuração do disco relevante é a seguinte:

• Windows 2003

• SEAGATE ST3500631NS (7200 rpm, 500 GB)

• RAID 5 baseado em LSI MegaRAID

• 4 discos, 1 hot spare

• Escreva através de

• Sem leitura antecipada
• Modo de cache direto
• Harddisk-Cache-Mode: desativado

Certamente, o RAID5 pode não ser o mais rápido, mas os discos compensam sendo mais rápidos do que em casa.

Mais alguns dados interessantes:

• Média Comprimento da fila: 30
• Média Comprimento da fila (leitura): 2

• Comprimento da fila (gravação): 26

• Bytes / s lidos: 1,3 MB / s

• Bytes / s escreve: 1.2MB / s

• Sec / Read: 0,007

• Sec / Write: 0,500

• Escritos por segundo: 36

Como posso resolver esse gargalo de gravação? É por causa das muitas pequenas gravações? Existe algum driver com defeito ou a possibilidade de acumular algumas transações para gravações maiores?

Os segundos por gravação são muito grandes!

Obrigado!

    

Answer 1

Eu suspeito que o RAID5 seja o principal culpado. Cada gravação de bloco em sua matriz pode resultar em leituras seguidas de duas gravações - na melhor das hipóteses (se o bloco extra já for lido no cache), serão duas gravações. Além disso, se os logs de transações e os arquivos de dados estiverem no mesmo array, cada gravação realizada pelo banco de dados resultará em duas gravações (uma no log e uma no arquivo de dados) - enquanto esse será o caso do sistema inicial também não fará muita diferença em sua comparação por si só, isso irá compor qualquer diferença de desempenho que de outra forma existe.

Sua unidade de disco rígido provavelmente tem seu cache ativado, o que ajudará a permitir que ele reordene as gravações para melhorar o desempenho, reduzindo o movimento da cabeça. Ativar a leitura antecipada pode ajudá-lo, reduzindo a contenção de cabeças com as operações de gravação, mas isso depende do padrão exato de E / S que sua consulta impõe.

O RAID10 é geralmente recomendado para bancos de dados, em vez de 5, por motivos de desempenho de gravação.

Quando você diz "os mesmos dados", um sistema executa um backup e restaura o banco de dados do outro? Se houver uma diferença no histórico dos dois bancos de dados, pode ser que o mais lento precise ter suas estatísticas de índice atualizadas (problemas inesperados de velocidade de consulta podem ser resultado de estatísticas básicas fazendo com que o planejador de consulta escolha um caminho menos ideal do que caso contrário seria).

Além disso, você tem o mesmo número de CPUs / núcleos nos dois ambientes? Algum tempo atrás eu vi o SQL Server 2000 levar mais tempo para executar uma consulta de gargalo de disco mais lenta ao usar dois CPUs do que quando foi dito apenas para usar o um, eu presumo porque tentou dividir a carga em dois CPUs, mas isso resultou em aumento Contenção de I / O devido a dois threads lendo juntos de diferentes lugares no disco (eu não vi isso mais recentemente, por isso pode ter sido um bug naquela edição + SP que é há muito tempo fixo, mas pode valer a pena procurar in para - se você estiver dando dicas de índice explícitas que ajudam em um ambiente de baixo nível, tente removê-las caso o planejador de consultas possa fazer escolhas mais adequadas aos núcleos extras, ou tentar manualmente reoptimizar as dicas você mesmo.

    

Answer 2

O cache write-through pode ser um impacto no desempenho. Cada gravação no cache deve ser gravada no disco imediatamente. Um cache de write-back pode esperar pelo momento ideal para gravar os dados no disco. Dependendo do hardware, isso pode exigir um backup de bateria (no controlador de matriz), e alguns controladores desativam o cache de gravação se a bateria estiver ausente ou precisar ser substituída. Você pode querer verificar se o cache da matriz está de fato ativado. Alguns controladores não tornam isso muito óbvio.

    

Answer 3

Eu tive um sério problema de IO em nosso datamart de BI. Descobri que alguém resgatou um dos discos rígidos configurados no RAID 5 e reconstruiu a paridade - de acordo com o suporte da HP; Ainda não sei o que começou a reconstruir.

Isso causou muitos problemas, mas quando a reconstrução está finalizada, recupero o desempenho. Esta pode não ser a resposta mais perspicaz, mas é uma das considerações que você deve fazer.