Recomendações de configuração de hardware do SQL Server

2

Estamos no processo de criar um novo servidor SQL e gostaríamos de algumas recomendações sobre hardware. Atualmente, construímos todos os sistemas internamente. Com as informações abaixo, o que você recomendaria para unidades e um compartimento SAS externo. Além disso, nessa carga de trabalho, quão benéfico seria o SAS versus SATA2?

Especificações básicas até agora:

  • CPU AMD Phenom II X4 955
  • 8 GB de RAM
  • Armazenamento de 2 TB RAID6 (pensando em 450 GB de unidades Seagate Cheetah de 15K.6)
  • Armazenamento RAID1 de 1 TB (por que abaixo) (1TB Seagate Barracuda ES.2)
  • Controlador SAS do 3ware 9690SA

Software:

  • Servidor Windows 2003 ou 2008 (ainda não decidido)
  • SQL Server 2005 ou 2008 (dependerá da compatibilidade de aplicativos)

Carga de trabalho:

Este servidor é relativamente pesado para leitura / gravação para a maioria das aplicações (cerca de 1TB) (finanças, aplicativos internos, etc.). Também temos dados GIS no servidor usado pelo ArcGIS. Nosso plano é ter nossos dados vetoriais na matriz RAID6 principal, com os dados rasterizados (cerca de 750 GB) na matriz RAID1 (já que seu uso não é tão frequente).

    
por Jon Bailey 01.07.2009 / 20:08

3 respostas

4

Eu sugeriria RAID10 para trabalho pesado de banco de dados que não fosse somente de leitura, nem RAID5 ou 6. Em um array RAID6 de 4 unidades cada bloco de gravação (ou gravação parcial de bloco) poderia ser transformado em leitura (para obter o outro bloco de dados) seguido por três gravações (uma para a gravação inicial, duas para os dois blocos de paridade) que podem ter um impacto significativo no desempenho de gravação. Com o RAID10, cada gravação de bloco (parcial) é apenas duas gravações no disco.

Se o acesso ao banco de dados incluiu muito poucas gravações, então RAID6 pode ser preferível para redundância, pois um array RAID6 pode sobreviver a duas unidades que falham no local - como uma matriz RAID10 de quatro unidades sobreviverá somente a quatro das seis combinações possíveis de duas drives, mas você afirma que espera que a atividade seja tanto leitura quanto gravação intensiva (e você tem bons planos de backup e recuperação de desastre, certo?).

Obviamente, certifique-se de optar por uma edição de 64 bits do Windows e do SQL Server, caso contrário, você não poderá usar toda essa RAM sem ataques de perda de desempenho como o PAE. Enquanto estamos na memória: eu sugeriria mais se você puder. A RAM não é cara hoje em dia, mesmo que seja uma RAM capaz de ECC com boa marca conhecida, então subir de 8 para o quanto você pode encaixar na placa não é uma má ideia. Para a maioria dos aplicativos no SQL Server (com bancos de dados grandes o suficiente), você observará o benefício sob qualquer carga considerável, pois reduzirá bastante as operações de E / S para consultas de leitura, pois um conjunto de trabalho maior pode ser mantido na memória. Pela sua descrição, parece que você tem um tamanho de dados e um padrão de atividade que se beneficiaria da quantidade de memória RAM que você pode praticamente jogar nele. Muitos novos servidores suportam 16Gb de RAM atualmente, e 32Gb não é incomum (e cada vez mais não há suporte para 64Gb, embora isso esteja entrando no mercado de "especialistas", então você pode ter que pagar um prêmio pelo adicional).

    
por 01.07.2009 / 20:42
3

Se o seu banco de dados estiver em uso intensivo, use o RAID 10, não o RAID 6. Com discos SAS realmente rápidos, muito bons.

Compre um chassi maior do que o necessário para poder crescer nele. Recentemente, adicionei um quad core ao meu servidor de banco de dados de produção - e posso dizer que, pela primeira vez na minha carreira, fiquei muito feliz por ter comprado a placa-mãe de soquete duplo, embora eu precisasse apenas de quatro núcleos para começar. A utilização da CPU vai de uma média de 60% com picos longos a uma média de 100% a 30%, com apenas picos de 100% raros tendo um enorme impacto no nosso desempenho. Não ter que migrar completamente de uma máquina para outra para conseguir isso foi realmente incrível - colocar outro chip no soquete extra demorou cerca de 20 minutos. Quanto a RAM; colocar o quanto a máquina pode levar.

Como nota, nosso sistema de produção usa SAS, nosso sistema de desenvolvimento usa SATA. Podemos definitivamente sentir e quantificar a diferença; consultas que podem precisar de 1,5 segundos em nossa máquina de produção carregada podem levar 3 segundos em nosso servidor de desenvolvimento não carregado. Isso é definitivamente anedótico, é claro, e há outras diferenças; mas notamos que IO é definitivamente o assassino. 1,5 segundos não é um grande problema, certo? Exceto na produção que é uma diferença de 1,5 segundo * x usuários * y solicitações por hora.

Mais uma ideia sobre IO: tivemos o cuidado de configurar nossas maiores tabelas mais usadas para estar em grupos de arquivos com vários arquivos. Um dos aprimoramentos de desempenho disso é que o SQL enviará solicitações para cada arquivo no grupo de arquivos - portanto, se BigOverUsedTable estiver em FileGroup1 e FileGroup1 tiver quatro arquivos nele e seu banco de dados tiver 8 núcleos, ele usará quatro núcleos para fazer "select" grande número esmagando consulta desagradável de BigOverUsedTable "- ao contrário, ele usará apenas uma CPU. Nós temos essa idéia neste artigo do MSDN:

link

Do TFA:

"Grupos de arquivos usam threads paralelos para melhorar o acesso aos dados. Quando uma tabela é acessada sequencialmente, o sistema cria um thread separado para cada arquivo em paralelo. Quando o sistema executa uma varredura de tabela para uma tabela em um grupo de arquivos com quatro arquivos, usa quatro segmentos separados para ler os dados em paralelo. Em geral, usar vários arquivos em discos separados melhora o desempenho. Muitos arquivos em um grupo de arquivos podem causar muitos encadeamentos paralelos e criar gargalos. "

Temos quatro arquivos em nosso grupo de arquivos em uma máquina de 8 núcleos devido a esse conselho. Está funcionando bem.

    
por 01.07.2009 / 20:17
0

O SAS é uma enorme vantagem sobre o SATA2 para operações de acesso aleatório. Eu evitaria SATA a todo custo. Você menciona a construção em casa, você já olhou para sistemas de rack como este?

link

Ele forneceria 20 compartimentos de unidade SAS em uma única unidade de montagem em rack. Adicione sua placa-mãe e controladores SAS de escolha.

    
por 01.07.2009 / 20:15