Ganhe até 30% de performance dos discos do servidor de banco de dados

 

Nesse post irei comentar sobre a importância de se fazer o alinhamento dos discos para obter melhor performance com o volume de dados no SQL Server. 
Antes de falar sobre a importância do alinhamento de discos, precisamos antes saber algumas nomenclaturas importantes.

Abaixo adicionei uma foto de um disco para podermos entender melhor.

image

Nomenclaturas:

Sectors: representa o menor pedaço de dados que pode ser lido ou escrito em um disco físico. A maioria dos discos possuem setores (sectors) de 512 bytes. Discos novos podem oferecer setores com tamanhos 1KB, 2KB, ou 4KB.

Clusters: são conhecidos por muitos como unidade de alocação de arquivo (file allocation unit). Seu tamanho é determinado quando a partição é formatada pelo Sistema Operacional. Cluster é definido por um grupo de setores (sectors) , seu tamannho ira depender do valor que foi definido para o file alocation unit. A maioria dos discos utilizam o tamanho de um setor de 512 bytes, considerando um file alocation unit de 64k então, 64K/512 bytes teremos 128 setores por cluster. Lembrando que Cluster = file alocation unit.

Track: cada lado de um disco (Platter) possui milhares de trilhas (tracks) onde são inseridos os setores (sectors) e por sua vez os clusters

Platters: são um ou mais pratos (Platters )de formato circular e de metal (quantidade depende do Hard Disk) onde são armazenadas as informações na superfície.

Stripe Unit Size: define o tamanho que os dados serão distribuídos entre os discos de um grupo RAID-0, RAID-10 ou RAID5.

Agora que entendemos as nomenclaturas podemos começar a falar sobre a importância de se alinhar um disco. O alinhamento de discos deve ser considerado para os volumes que são utilizados pelos arquivos de dados e transaction log do SQL Server. 
Outra consideração importante é que o alinhamento deve ser considerado no Windows Server 2003 que não faz o alinhamento do disco por default. No Windows Server 2008 o alinhamento de discos é feito de forma automática, no entanto eu quero deixar um alerta devido ao que tenho visto em meus clientes aqui nos EUA que estão utilizando Windows Server 2008 e mesmo assim não estão com os discos alinhados. Em caso de migrações de Windows Server 2003 para Windows Server 2008, geralmente a storage é apresentada para o novo Sistema Operacional, no caso o Windows Server 2008, sem precisar redefinir os particionamentos. Mesmo sabendo que no Windows Server 2008 o alinhamento é feito por default, nesse caso não será feito porque as partições foram criados enquanto estavam no Windows Server 2003. O alinhamento é feito durante a criação da partição.

Para entendermos o porquê é necessário o alinhamento de um disco, devemos entender que todo disco usa algum espaço para armazenar informações sobre a partição, que então irão utilizar alguns setores ocultos (hidden sectors). Especialmente no Windows Server 2003 são reportados 63 setores ocultos por default. Considerando que cada setor possui 512 bytes então temos que 63 * 512 = 31.5 K que o disco ira utilizar para armazenar informações sobre a partição.

Tendo esse numero em mente vamos entender porque o disco fica desalinhado. Guarde bem em sua memória esses numeros.

Se você precisar consultar a nomenclatura acima novamente, sinta-se a vontade. Para refrescar a sua memória o Stripe Unit Size é determinado pela equipe de Storage no momento de criação das Luns, vamos considerar 64K para o nosso exemplo. Stripe Unit Size é o tamanho do “pedaço” de dados que será distribuído entre os discos de um Array da Storage.

Temos a seguinte configuração para usarmos como exemplo.

Stripe Size = 64K 
Alocation Unit Size ou Cluster Size = 64K 

Exemplo de um disco desalinhado.

disk

No exemplo acima podemos ver uma situação de disco desalinhado, o Stripe Unit Size definido pela equipe de storage, possui um tamanho de 64k e esta representado na cor Azul na primeira linha da figura. O Stripe Unit Sizedefine os limites fisicos de armazenamento para o Array. 
Na segunda linha em amarelo podemos ver os setores que são utilizados para armazenar informações sobre a partição. Lembre-se que no Windows Server 2003 por default é utilizado 63 setores, considerando que o tamanho do setor é 512 bytes então teremos 31.5 K. Eu disse para você memorizar esse número. Repare que esse valor não preenche totalmente o tamanho definido pelo Stripe Unit Size que é 64K, deixando um espaço a ser preenchido. Então imagina o que irá acontecer quando os dados de usuário começar a ser gravado no disco.

Como exemplificado na linha 3 os dados de usuário, representado na cor verde, que nesse caso possui tamanho de alocação de 64K, definido pelo Alloc Unit Size, ira ser inserido entre dois espaços definidos no disco pelo Stripe Unit Size. Sempre que um dado de usuário ser inserido nos próximos espaços estará desalinhado em relação ao Stripe Unit Size definido para o Array.

Então como podemos resolver esse problema? Imagine se de alguma forma você reservasse um espaço para armazenamento de informações sobre a partição, onde o dado representado em amarelo preenchesse os 64K ao invés de 31.5K e então utilizar todo espaço definido pelo Stripe Unit no nosso exemplo a area em azul. Aconteceria que o próximo dado de usuário a ser inserido, representado em verde, iniciaria a partir do segundo Stripe Unit de 64K, evitando que a alocação feita pelo usuário não estaria entre dois espaços definidos pelo Stripe Unit. Consequentemente evitando o IO em dois lugares distintos onde precisaria apenas um.

Vamos ver agora como ficaria um exemplo utilizando um alinhamento onde reservaremos todo o espaço de 64K definido pelo Stripe Unit.

 

Untitled1

Nesse exemplo acima ao inves de usar o alinhamento default do Windows Server 2003 e  utilizar apenas 31.5K, fizemos diferente e definimos o parametro align para 64K que esta representado em amarelo. 
Isso irá preencher todo o espaço de 64K definido pelo parametro Stripe Unit, então as próximas alocações de dados de usuários, iniciara e terminara dentro do espaço definido pelo Stripe Unit
Mesmo se for definido o Alloc Unit size/Cluster Size que é o bloco de dados gravado pelo usuário de 4K, estara ainda assim dentro do limite de 64K. Nesse caso serão necessarios 16 blocos de alocação de dados para preencher um Stripe Unite. Repare 16 * 4 = 64K portanto ainda estara alinhado.

Após entender essa teoria concluímos que o parâmetro Align dividido pelo Stripe Unit Size devera ser um numero inteiro sempre.

Como não se sabe a quantidade de espaço necessário para armazenar informações sobre a partição para os diferentes discos existentes no mercado, então a Microsoft recomenda utilizar o valor de alinhamento como 1024k ou 1MB. 
Isso significa que assim como fizemos com 64k reservando espaço para dados de partição para garantir que os dados de usuário sejam gravados de acordo com o Stripe Unit, que nesse exemplo é 64K, podemos fazer o mesmo usando o valor 1024K recomendado pela Microsoft.

Se pegarmos o exemplo que usamos anteriormente usando um alinhamento de 64k ao invés de 31.5K (Windows Server 2003 Default) e um Stripe Unit Size de 64K temos o seguinte:

64K / 64K = 1   onde o resultado é igual a 1 bloco de Stripe Unit.  Representado em amarelo, usamos 1 unidade parasetores ocultos, para então iniciar a gravação dos usuários de acordo com os limites fisicos definidos pelo parametroStripe Unit Size.

Podemos fazer o mesmo com o parametro de alinhamento 1024K e Stripe Unit Size de 64k

1024K / 64K = 16 o resultado aqui é também um numero inteiro, que significa que antes de iniciar a gravação de dados de usuários, iremos preencher 16 unidades de amarelo para setores ocultos, para então iniciar a gravação dos dados de usuário. Isso irá resultar que serão preenchidos 16 unidades de 64K para iniciar a gravação dos dados de usuário, que por sua vez estará alinhado com os limites fisicos definidos por Stripe Unit Size

Considerações

Align value : Stripe Unit Size deve ser um numero inteiro para que o disco grave de forma alinhada. 
Allocation Unit Size que são blocos de dados de usuário, recomenda-se ser o mesmo valor de Stripe Unit Size.

Espero que tenham gostado do Post sobre alinhamento de discos e aguardo comentários caso tenham alguma dúvida. Em um outro post mostrarei como fazer o alinhamento de discos.

 

Como saber se seus discos estão alinhados? Eis as contas:


 
Partition_Offset ÷ Stripe_Unit_Size
Stripe_Unit_Size ÷ File_Allocation_Unit_Size

Pegando o valor do Partition_Offset: no prompt do DOS digite :

wmic partition get BlockSize, StartingOffset, Name, Index

Em um servidor 2008, o resultado esperado seria:
 



Como até o Windows 2003, o default do StartingOffset era de 31.5 kb, o problema se tornou muito comum. No Windows 2008 este problema foi corrigido, e o StartingOffset por default é de 1 MB.

Lembrete: Em alguns casos, o vendor pode ter um valor específico ideal para o StartingOffset. 


A informação do Strip_Unit_Size não se encontra no Windows e varia de acordo com o fabricante, quantidade de discos em RAID e RAID, mas em alguns casos é equivalente a Bytes per Cluster, que pode ser obtida em:

fsutil fsinfo ntfsinfo DRIVE:
 

A informação de Bytes per Cluster é IMPORTANTÍSSIMA. Lembre-se: o SQL Server trabalha com escrita em blocos de 64k. Portanto, discos com blocos de 8k ou 4k (que é o default) terão muito mais trabalho, e por consequencia overhead na escrita. De acordo com o artigo em questão, a recomendação (no geral) para datafiles e logfiles de Analysis Services é 32k.

Pelo fsutil, fechamos a conta (usando o Drive D, disk #1 como exemplo).


1048576 / 4096 = 256 (Número inteiro, está alinhado)

 
4096 / 4096 = 1 (Número inteiro, está alinhado; levando em consideração que o Strip_Unit_Size seja 4k. Caso seja de 64k, o retorno também é inteiro)

O único ponto negativo neste cenário é o bloco de 4k. Conforme vimos acima, a recomendação geral da MS é a utilização de blocos de 64k, porém afirma-se que a blocagem tem impacto menor na performance que o alinhamento.

 

No caso do Oracle não é diferente, veja o artigo:

http://www.dba-oracle.com/oracle_tips_raid_usage.htm

 

 

Para maiores informações e detalhes recomendo a leitura do Whitepaper Disk Partition Alignment Best Practices for SQL Server http://msdn.microsoft.com/en-us/library/dd758814(v=sql.100).aspx

Autor: André Hass – Premier Field Engineer – US East Region / Leandro Buffone

 

 

Crie um site com

  • Totalmente GRÁTIS
  • Centenas de templates
  • Todo em português

Este site foi criado com Webnode. Crie um grátis para você também!