Alinhamento dos discos – Melhores práticas para o SQL Server 2008

Esse é um assunto que a grande maioria dos administradores de banco e de redes deixa passar batido… seja por desconhecimento ou simplesmente por achar que os ganhos de performance são tão insignificativos que não vale a pena o esforço… mas que como vamos ver vale sim a pena ser discutido…

Eu não vou explicar detalhe a detalhe sobre esse assunto porque irei indicar um White Paper específico sobre esse assunto que irá fornecer inclusive scripts para lhe ajudar com a tarefa de criar discos alinhados. Entretanto, uma pequena introdução sobre o que é e quais os benefícios do alinhamento dos discos é necessário.

Nossos discos são divididos da seguinte forma… temos as Tracks, que são divididas em Clusters (ou allocation unit size no windows) e cada cluster é dividido em setores, os setores são a quantidade mínima de dados que podem ser lidos ou gravados no disco.

O desalinhamento dos discos ocorre porque essa notação, chamada de C/H/S (cylinder/head/sector) não corresponde com a realidade física dos discos. Todos os discos modernos fazem um arranjo das tracks diferente, e expõem o número de tracks e setores somente para o cálculo do espaço total disponível, entretanto todas as versões do windows anteriores ao windows server 2008 levava em consideração essa notação CHS para a formatação do disco, o que causava que setores lógicos na verdade não correspondessem com os mesmos setores físicos do disco. Então por exemplo, quando o disco recebe 1 operação de escrita, de 1 setor, fisicamente ele pode ter que fazer 2 operações de escrita para armazenar aquela informação.

Vocês podem notar isso nessa imagem, onde temos os primeiros 63 setores reservados para o disco, nesse setores que fica a MBR por exemplo. Logo após temos clusters de 4KB e podemos perceber que a cada 8 clusters estamos cruzando a borda física entre 2 clusters, então TODA operação de leitura e escrita nesses clusters irá na realidade precisar de 2 IOs.

Em servidores que fazem muito acesso a disco, como por exemplo o SQL Server, Exchange Server, etc. essa leitura de IO adicional pode ter consequencias de performance graves.

O ganho de performance do alinhamento desses discos para que os mesmos utilizem sempre 1IO para uma determinada operação chega na casa dos 30%!

Em um dos casos apresentados no white paper a seguir uma empresa de telecom conseguiu reduzir a janela de manutenção de 4 horas para 90 minutos. Inserir 1 milhão de linhas em uma tabela com 140 milhões de linhas demorava 6:59 minutos na configuração padrão dos discos, depois do alinhamento esse valor caiu para 52 segundos.

Consegui a atenção de vocês? Realmente o particionamento dos discos traz sim bons ganhos de performance em sistemas que tem muitas operações de IO. Essa explicação inicial era para ser apenas uma introdução MUITO básica sobre o assunto.. para uma explicação detalhada do problema e de como alinhar seus discos acessem o seguinte white paper abaixo.

Como sempre.. qualquer dúvida sobre o assunto, sugestão ou esclarecimento é só deixar um comentário abaixo ;)

http://msdn.microsoft.com/en-us/library/dd758814.aspx - Disk Partition Alignment Best Practices for SQL Server

Apenas como observação: o tamanho padrão do cluster (allocation unit size) no windows não é otimizado para servidores de banco de dados e/ou com grande acesso de IO, por isso se você utilizou a formatação padrão do windows com os valores padrões para o allocation unit size então as chances de seu disco estar desalinhado e utilizando mais IOs que o necessário é grande. Isso é válido para todas as versões do windows anteriores ao windows server 2008.