Otimizando a E / S de Disco e o RAID no Windows SQL Server 2005

Question

Tenho monitorado nosso servidor SQL há algum tempo e percebi que a E / S atinge 100% de vez em quando usando o Gerenciador de Tarefas e o Perfmon.

Eu normalmente consegui correlacionar esse pico com processos SUSPENDED no SQL Server Management quando executo "exec sp_who2".

O controlador RAID é controlado pelo Gerenciador de armazenamento LSI MegaRAID. Nós temos a seguinte configuração:

1. Unidade do sistema (Windows) no RAID 1 com duas unidades de 280 GB
2. O SQL está em um RAID 10 (2 unidades espelhadas de 280 GB em dois períodos diferentes)

O servidor é uma máquina de 64 bits com mais de 50 GB de RAM. SQL 2005 64bit está sendo executado no Windows 2003 64 bits. Infelizmente, o aplicativo é executado em cima do jBoss, que atualmente é uma versão de 32 bits (mas estamos pressionando o provedor de software a nos colocar em uma versão de 64 bits do jBoss).

Este é um banco de dados que é martelado durante o dia, mas é bastante inativo à noite. O tamanho do DB atualmente é de cerca de 13 GB e é usado por aproximadamente 200 (e crescentes) usuários por dia.

Eu tenho algumas idéias com as quais estou brincando:

1. Verificando índices & reindexando algumas tabelas
2. Adicionando um RAID 1 adicional (com 2 HDs novos e menores) e movendo o LDF (Log Data File) do SQL para o novo RAID.

Para o nº 2, minha pergunta é a seguinte: Estaríamos realmente aumentando o desempenho do disco (IO) movendo os dados do RAID 10 para um RAID 1? O RAID 10 obviamente tem melhor desempenho que o RAID 1. Além disso, o SQL deve gravar nos logs de transação antes de gravar no banco de dados.

Mas por outro lado, estaremos reduzindo tanto o tamanho dos discos quanto a quantidade de dados gravados no RAID 10, que é onde toda a "carne" está - aumentando assim o desempenho do RAID para ler pedidos.

Existe alguma maneira de descobrir qual é o nosso fator limitante atual? (As unidades versus o controlador RAID)? Se o fator limitante for as unidades, talvez seja necessário adicionar o RAID 1 adicional. Mas se o fator limitante é o próprio Controlador, então acho que estamos nos aproximando dessa coisa errada.

Finalmente, estamos apenas perdendo nosso tempo? Deveríamos, ao invés disso, estar concentrando nossos esforços em direção a # 1 (reindexing tables, reduzindo a latência da rede quando possível, etc ...)?

    

Answer 1

Acho que sempre há uma vantagem em separar os arquivos do banco de dados e os arquivos de log em matrizes RAID separadas. E / S do arquivo de banco de dados é sempre aleatória, enquanto a E / S do arquivo de log é sempre seqüencial. A mistura desses tipos de E / S na mesma matriz RAID sempre induzirá uma penalidade de desempenho (embora possa não ser aparente se houver muito pouca carga de E / S na matriz). Eu acho que seu ponto # 2 está bem recomendado, embora, como mrdenny afirmou, você provavelmente tenha problemas de banco de dados (índices, etc.) se estiver vendo E / S de disco tão alto quanto estiver com um banco de dados desse tamanho e 200 usuários. / p>

Estou executando um único SQL Server (2005 Standard) com, em média, 2000 conexões com 125 bancos de dados sem o problema de desempenho que você está vendo. Temos uma matriz RAID1 única para os bancos de dados e outra matriz RAID1 para os arquivos de log.

Além disso, não ignore o alinhamento da partição (volume) como uma possível causa do seu problema de desempenho.

Além disso, dê uma olhada nestes artigos:

link

link

link

link

    

Answer 2

É provável que você precise corrigir alguns problemas de indexação com o seu SQL Server. Um banco de dados de 13 Gig com 200 usuários não deve estar forçando muito o disco, a menos que os usuários estejam executando algumas consultas muito complexas e não haja RAM para o sistema.

Eu não me importaria em adicionar qualquer hardware (exceto talvez mais memória RAM), dependendo se você é x32 ou x64 e qual versão e edição do SQL e do Windows você está usando.

    

Answer 3

Para os arquivos de log, eles devem estar em fusos separados, o que significaria unidades de disco, raid arrays e volumes separados. A razão para isso é que a gravação de log é seqüencial e deve ser executada o mais rápido possível, em grandes unidades de alocação, sem ter que lidar com outro acesso ao banco de dados (seja gravando no banco de dados ou consultando).

Seus volumes devem ter um tamanho de unidade de alocação de 64k e, como mencionado por joqwerty, é mais provável que você também sofra de partições desalinhadas, porque as partições do Windows estão desalinhadas por padrão no Windows 2003. Em alguns casos, o impacto no desempenho pode ser significativo , tanto quanto 30 a 40%. O seguinte artigo descreve como recriar partições que estão alinhadas corretamente:

Práticas recomendadas de alinhamento de partição de disco para o SQL Server
link

Não tenho certeza do que você quer dizer com "reindexação". Se estiver reconstruindo ou reorganizando, isso é algo que deve fazer parte de um plano de manutenção diária. E se você não sabe como seus índices estão fragmentados, então você tem algumas informações básicas para fazer antes que qualquer ação seja tomada. Eu não estaria muito ansioso para criar novos índices, a menos que você tenha dados empíricos para suportar isso. Em particular, os bancos de dados que são atualizados frequentemente (OLTP) devem ter o menor número de índices possível, porque cada índice retarda o desempenho da atualização. Já vi pessoas fazerem mais mal do que bem ao "bombardear" um banco de dados com índices.

Finalmente, você pode querer verificar se o seu controlador RAID tem o cache de gravação ativado. Eu vi muitas pessoas perderem isso. Às vezes, o cache de gravação pode ser desativado devido à necessidade de substituição da bateria ou porque não sabiam que precisavam de uma bateria para ativar o armazenamento em cache.