Conselhos sobre configuração de hardware para o SQL Server 2005

Question

Atualmente estou tendo problemas com um servidor de banco de dados para um banco de dados com muitas gravações pequenas e algumas em grandes leituras de comparação. O desempenho de leitura é mais importante porque as pessoas estão envolvidas, as gravações são realizadas por clientes automatizados. Este banco de dados tem atualmente 30 GB e crescerá até uma centena.

A configuração atualmente horrível e feia que tem um desempenho inferior é

• DELL Poweredge R300
• Quad Core Xeon X3353 a 2,66GHz
• 14 GB de RAM
• SAS 15k 146 GB (duas partições, um SO, outros Logs)
• SAS 15k 146 GB (uma partição, dados e tempdb)
• Sem RAID (ugh)
• SATA 7k 1TB [via USB 2.0, fonte de alimentação externa, onde os backups diários são armazenados]

Portanto, devido a seus muitos pontos desagradáveis (baixo desempenho, sem RAID, drive USB externo para backups), estou planejando configurar um novo servidor de banco de dados.

Eu pensei sobre:

• 4 SAS 15k RAID10 de 73 GB para logs
• 2 SAS 15k RAID1 de 73 GB para SO
• 4 SAS 15k 146 GB RAID10 para dados + tempdb
• 32 GB de RAM

Então, três perguntas:

• Essa é a melhor combinação de preço / desempenho? Isso é um exagero? Existe uma combinação melhor? Mais informações são necessárias?

• Você sabe de uma única máquina com preços razoáveis que pode conter os 10 discos ou devo ir para um armazenamento externo conectado localmente agora?

• Alguma recomendação para obter algo assim a um preço / qualidade razoável?

Answer 1

32 GB de RAM é um bom número redondo típico para a maioria das CPUs do Servidor, mas se você estiver olhando para as CPUs Xeon 5500 (Nehalem), lembre-se de que elas estão configuradas de maneira ideal em bancos de 3 DIMMs por CPU e múltiplos de 6 DIMMs para servidores de soquete, assim você verá um melhor desempenho com 24 \ 48GB de RAM em vez de 32GB.

Existem muitos servidores que aceitam 10 discos, mas se você os consideraria com preços razoáveis ou não, não posso dizer. Duvido que você encontre qualquer 1U como o R300 que terá 10 discos - o 360 G6 da HP pode empinar 8 unidades SFF de 2,5 "em 1U por um preço básico de apenas US $ 2K. O R610 da Dell é aproximadamente equivalente (também é 1U dual socket Xeon 5500 system), mas só recebe 6 drives internamente, mesmo que você bata com os servidores de classe 2U DL380 \ R710

Torres de rack como a HP ML370 G6 funcionam por cerca de US $ 2,5 mil, mas podem levar até 24 unidades. O T710 da Dell custa cerca de 16.

Os preços acima são os preços mínimos de lista para o chassi com 1 CPU, sem discos e praticamente sem RAM. Um HP ML370 configurado com essas unidades, 24 GB de RAM e dois Xeon E5540 terão um preço de lista de cerca de US $ 10 mil. A maior parte disso vem de suas escolhas de unidade - você poderia economizar cerca de US $ 1.500,00 optando por uma única variante de soquete, mas o custo marginal da RAM pode aumentar, pois os DIMMs DDR3 de 4GB são cerca de 50% mais caros por GB que 2GB módulos.

Editado para adicionar uma ideia das comparações de desempenho.

Um Xeon 5540 2.53Ghz CPU será cerca de 50% melhor relógio para relógio comparado ao seu CPU existente. Uma configuração de soquete duplo com o SQL 2005 deve ser dimensionada de maneira razoavelmente eficiente, portanto, em termos puros de CPU, um sistema de soquete duplo como os listados acima terá cerca de 3x o poder de CPU de seu R300.

Configure com RAM DDR3 balanceada @ 1066Mhz você deve ver cerca de 3x a largura de banda de memória, possivelmente mais porque suspeito que sua configuração atual do R300 não é a ideal.

Em termos de desempenho de disco, você está aumentando sua capacidade de E / S aleatória efetiva em pelo menos um fator se 5 (obviamente o suficiente), mas adicionando um controlador RAID avançado decente e segregando a funcionalidade adequadamente provavelmente verá melhorias de desempenho substancialmente melhores além disso.

O chipset Tylersburg usado em (quase) todos os atuais sistemas baseados no Xeon 5500 também separa o Memory IO e o restante, o que é mais difícil de quantificar, mas terá, invariavelmente, algum benefício.

Esses sistemas são muitas vezes mais rápidos do que a sua configuração existente, mas se isso realmente se traduz em melhor desempenho para seus usuários depende de quais são os seus gargalos atuais. Se for um aplicativo mal projetado ou o congestionamento da rede melhorando o servidor, isso não resultará em ganhos tão claros.

    

Answer 2

Se você tiver muitos discos, por exemplo em alguma forma de SAN, o RAID10 é a escolha óbvia, pois combina velocidade e tolerância a falhas. No entanto, na maioria dos casos, há um limite no número de discos que podem ser instalados em um servidor e, nesse caso, é necessário considerar o RAID5 como uma alternativa.

Seus arrays RAID10 de 4 discos têm aproximadamente a mesma velocidade que um disco RAID0 de 2 discos, ou um pouco menos do que o dobro da velocidade de um disco sem disco, para que não sejam tão rápidos. Usar um RAID5 de 4 discos em vez daria uma matriz com velocidade de leitura e gravação de streaming mais rápida, mas velocidade de gravação de acesso aleatório um pouco mais lenta (testei isso em um controlador Dell Perc5 / i e presumo que seja verdade para outros controladores). / p>

Eu consideraria usar seus 10 discos como um RAID10 de 6 discos e um RAID5 de 4 discos. Divida o RAID5 em uma pequena partição C: para o sistema operacional e o restante como uma partição D: para os arquivos de log. Os logs tendem a ser gravados em seqüência para que a velocidade de acesso aleatório mais lenta não seja um problema. Coloque os dados no RAID10 onde eles se beneficiarão da alta velocidade de acesso aleatório, particularmente a alta velocidade de gravação de acesso aleatório.

NB Não estou recomendando que você organize os discos como RAID10 e RAID5, no entanto, estou recomendando que você teste usando os discos neste formato e compare a velocidade com sua sugestão de RAID1 + RAID10 + RAID10.

JR

    

Answer 3

Antes de começar a comprar hardware, eu fazia algumas investigações com o Monitor de Desempenho para garantir que os discos estivessem atrasados. Se os problemas de desempenho são causados pelo bloqueio por esses "clientes automatizados", você pode achar que o desempenho no novo servidor não é muito diferente do que você tem agora.

Editar # 1: Eu gosto de olhar para a média. Números de disco sec / transferência. Estas são, essencialmente, uma medida da latência do disco. Eu costumava usar os números da fila, mas você deveria dividi-los pelo número de fusos na matriz RAID. Você nem sempre sabe esse número, especialmente com o armazenamento SAN, e os Microsoft Ninjas me disseram para desistir dos números de profundidade da fila, em 2002 ou mais.

(Normalmente, eu vejo os números de segundos / transferências, os números de leitura e escrita por segundo (eles dão uma boa noção de como o disco está indo) e os valores lógicos e físicos de leitura da página (ajuda a detectar quando algum outro , SQLServer não está usando o disco e quando o SQL está apenas varrendo muitos dados fora da RAM.O último valor está sob os contadores SQL, não os contadores de disco.E claro, a utilização do processador antigo, é claro, para cada núcleo disponível (em vez de "total").

Com a média Valores de sec / tranfer do disco, apenas procuro valores médios abaixo de 50 ms para unidades de dados e 20 ms para unidades de log. Observe que sua configuração atual tem o sistema operacional e os logs nos mesmos eixos, o que significa que eles lutarão pelo controle dos cabeçotes da unidade e isso aumentará suas latências.

Observe que altas taxas de leitura para bancos de dados podem significar meramente indexação incorreta. É muito difícil trabalhar com problemas de indexação em um fórum da web. Com tanta RAM na nova caixa, você pode acabar armazenando quase todos os dados na RAM. Isso reduzirá a carga nos discos, mas você pode se deparar com alta utilização do processador, pois o SQL ainda precisa verificar todos esses dados; é só na RAM, e não no disco. Tê-lo na RAM será mais rápido que no disco, mas ainda será mais lento que um banco de dados bem indexado.

Além disso, eu tentaria manter meus dados e tempdb em diferentes conjuntos de fusos, porque quando você está fazendo gravações pesadas em tempdb, geralmente significa que você está fazendo leituras pesadas a partir dos dados (algo como select * em #report from huge_table, ou possivelmente use de distinct ou group by para grandes conjuntos de resultados). Se o seu aplicativo não usar muito o tempdb, isso pode não importar muito.

Para um SQL Server bem ajustado, você não precisa armazenar o banco de dados inteiro na RAM. Eu tenho servidores com 12 GB de RAM que o servidor de 100 GB de dados.

Além disso, você provavelmente poderia economizar um pouco de dinheiro, indo com 10KRPM drives para o sistema operacional. Uma vez que o SQL esteja instalado e funcionando, ele não deve tocar muito a unidade de inicialização.

Se eu estivesse no seu lugar, ficaria mais preocupado com a falta de redundância de RAID na sua configuração atual, seguida por (provavelmente) longos períodos de backup nessa unidade USB.

Se eu ficasse preso à unidade USB por um tempo, talvez eu parecesse fazer um backup COMPLETO uma vez por semana, seguido por backups DIFERENCIAIS uma vez por dia. Dependendo de quanto de seus dados realmente muda em um determinado dia, isso deve reduzir a quantidade de dados que você precisa mover para a unidade USB.

    

Answer 4

Tantas perguntas ...

Este é um servidor SQL dedicado? (deve ser!) 32GB RAM está bem e CPU parece bem ...

Esse servidor hospeda apenas esse banco de dados único ou está sendo usado por muitos aplicativos com diferentes bancos de dados?

qual é a carga de trabalho do servidor? Quantas transações por segundo (leitura / gravação)?

Qual é a importância dos dados? Se for muito importante (ou seja, não deve perdê-lo), faça uma polarização na construção para redundância. Se tiver que estar 100% disponível (sem tempo de inatividade), faça um viés de resiliência (e obtenha um orçamento maior). Se for apenas um banco de dados de desempenho (ou seja, um data warehouse), você poderá otimizar o desempenho.

Você deve examinar os contadores de desempenho para descobrir onde está o afunilamento atual. E / S de disco alto e filas de disco? CPU alta? (geralmente causado por RAM limitada e lixo de contexto)

O código SQL está escrito corretamente? Eu vi grandes máquinas (e a sua é bem grande) trazidas de joelhos por um pobre código SQL e máquinas minúsculas (1 CPU, 1GB de RAM) carregam cargas de bancos de dados bem escritos e ocupados.

Geralmente, mantenha-se longe do RAID 5 (o tamanho do banco de dados é pequeno o suficiente para não precisar de capacidade extra), o RAID10 é o melhor.

Separe DATA e TEMP em diferentes arrays de unidades.

Você deve usar uma unidade dupla RAID 1 para LOGS, uma unidade dupla para TEMP (criar tantos arquivos de dados TEMP quanto CPUs nas duas unidades) e depois os DATA podem estar em uma matriz RAID10 de 4 a 6 maiores. / p>