Um sistema que estamos desenvolvendo consiste em um front-end de aplicativo Web e um back-end que processa muito dados usando procedimentos armazenados no SQL Server 2008 R2 (por favor, não pergunte por quê...). Esses procedimentos armazenados fazem uso intenso de tabelas temporárias (criação, inserções, junções), de modo quetempdba taxa de E/S é alta em gravações e leituras. Nossos clientes precisam de velocidade, por isso estamos prestes a recomendar o seguinte:
- Compre um servidor com um array SSD RAID 1 para armazenar o banco de dados principal (talvez RAID10 se eles tiverem dinheiro), usando outro disco rígido para a instalação do sistema operacional e do SQL Server, para que os dados vitais sejam armazenados com replicação em uma unidade rápida, e 64 GB de RAM.
- Use um Ramdisk para armazenar otempdbbanco de dados, portanto, as tabelas temporárias (o maior gargalo de desempenho, acreditamos) são processadas na RAM.
Alguns dados de contexto:
- Nosso banco de dados não utiliza mais do que 10 GB, com uma taxa de crescimento esperada muito baixa. O Tempdb geralmente não ultrapassa 2 a 3 GB.
- O servidor será usado para o banco de dados e o servidor web.
- O software Ramdisk pode montar o ramdisk na inicialização do Windows.
Testamos a abordagem do disco RAM em um laptop com muita memória RAM. A aceleração é notável (tempos de execução de procedimentos armazenados reduzidos para 1/3), pelo menos.
Preciso de ajuda para determinar se esta é uma boa solução ou não e para detectar quaisquer falhas (óbvias ou menos óbvias) que possam estar faltando.
EDIT: Obrigado pelas respostas até agora! Esqueci de mencionar explicitamente que haverá usuários simultâneos usando o aplicativo, portanto, haverá várias operações de tabela temporária em execução. Além disso, misturar servidor web e servidor de banco de dados não é nossa escolha, já sabemos que não é o ideal;)
Responder1
Não é apenas a taxa, é a espera. Compare corretamente. Verifique o IOPS, além do comprimento da fila do disco. Use perfis Perfmon e SQL. Vá em frente - vou esperar.
Você já sabe que o sistema operacional deve estar em um conjunto de eixos, MDFs em outro, LDFs em outro e arquivos tempdb em outro, se você tiver problemas reais de desempenho. Se você não pode se comprometer a fazer isso, compare-o e descubra suas prioridades. Além disso, os diferentes padrões de leitura e gravação podem ditar diferentes níveis de RAID para cada um deles.
Você pode descobrir que os discos padrão com as configurações RAID corretas podem levá-lo onde você precisa, e não se esgotar no SSD corporativo. Embora, se o tempdb estiver sendo prejudicado o suficiente, um único SSD pode ser uma boa opção para ele. Provavelmente não há necessidade de RAID para desempenho, embora para redundância possa ser uma boa ideia. Depende do seu orçamento e de quanto tempo você pode ficar inativo, é claro.
Você também sabe que o servidor SQL deve ser separado do servidor web, certo? Se o desempenho é uma preocupação? Mesmo que você não esteja tendo problemas agora, se você crescer, terá dificuldade em determinar o que está sendo martelado com mais força e qual é a solução apropriada.
Responder2
RAID é pararedundância, o desempenho sai pela janela. Por exemplo, RAID 5 para ler um dadotodosos discos componentes devem ser lidos e a paridade verificada (queémais lento do que a leitura de um único disco, os movimentos da cabeça não serão necessariamente sincronizados, portanto você está aguardando omais longodo conjunto, não apenas a média), escrever significa ler tudo, calcular a paridade e escrever novos dados e paridade, claramente mais lento do que apenas escrever.
Sim, uma boa implementação de RAID e um sistema operacional inteligente podem mitigar muito isso (é necessário, mesmo discos únicos são terrivelmente lentos em relação à RAM, portanto, qualquer sistema operacional que se preze faz um cache extenso, independentemente dos discos).
Sim, um SGBD inteligente também armazenará dados em cache na RAM tanto quanto possível (respeitando as promessas feitas com relação à consistência dos dados, resistência a falhas e assim por diante; quando necessário, ele aguardará explicitamente que os dados estejam seguros no disco antes de prosseguir).
Para qualquer banco de dados, um RAMdisk é puro veneno ("dados gravados explicitamente no disco, portanto seguros" não são).
Responder3
Obrigado por todas as respostas. Eles têm sido muito úteis. Após algumas pesquisas subsequentes, descobri que a velocidade de E/S não era o principal gargalo neste caso específico, embora seja importante em geral. As melhores práticas no gerenciamento de tempdb incluem ter pelo menos 4 arquivos de dados. A Microsoft também recomenda 1 arquivo de dados para cada núcleo da CPU. Ter mais arquivos ajuda a reduzir alguns tipos de problemas de contenção.
Alguns links sobre isso:
Responder4
para que a taxa de E/S do tempdb seja alta em gravações e leituras
Pouca RAM. tempdb apenas IO quando transborda - caso contrário, o SQL Server não despeja as páginas tempdb no disco.
Portanto, um disco RAM não ajudará - em vez disso, coloque mais memória.