Acelerando o processamento da tabela temporária do SQL Server com um Disco RAM

Question

Um sistema que estamos desenvolvendo consiste em um front-end de aplicativo Web e um back-end que faz muito processamento de dados usando procedimentos armazenados no SQL Server 2008 R2 (por favor, não pergunte por que ...). Esses procedimentos armazenados fazem uso intenso de tabelas temporárias (criação, inserções, junções), de modo que a taxa de E / S de tempdb seja alta em gravações e leituras. Nossos clientes precisam de velocidade, por isso estamos prestes a recomendar o seguinte:

• Compre um servidor com uma matriz SSD RAID 1 para armazenar o banco de dados principal (talvez RAID10 se tiver 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 a replicação unidade e 64 GB de RAM.
• Use um Ramdisk para armazenar o banco de dados tempdb , para que as tabelas temporárias (o maior gargalo de desempenho, pensamos) sejam processadas na RAM.

Alguns dados de contexto:

• Nosso banco de dados usa no máximo 10 GB, com uma taxa de crescimento esperada muito baixa. O Tempdb geralmente cresce até não mais do que 2-3 GB.
• O servidor será usado para o banco de dados e o servidor da Web.
• O software Ramdisk pode montar o ramdisk na inicialização do Windows.

Nós testamos a abordagem ramdisk em um laptop com muito ram. A aceleração é notável (tempos de execução do procedimento armazenado reduzidos a 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 ausentes.

EDITAR: 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, a mistura de servidor web e servidor de banco de dados não é nossa escolha, já sabemos que não é ideal;)

    

Answer 1

Não é apenas a taxa, é a espera. Benchmark corretamente. Verifique o IOPS, além do comprimento da fila de disco. Use o perfil 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 e outro, se você tiver problemas reais de desempenho. Se você não pode se comprometer a fazer isso, faça um benchmark 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 corretas de RAID podem levá-lo aonde você precisa estar, e não trabalhar para o SSD corporativo. Embora, se o tempdb está sendo martelado o suficiente, um único SSD pode ser um bom ajuste 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 quanto tempo você pode estar em baixo, é claro.

Você também sabe que o servidor SQL deve ser separado do servidor web, certo? Se o desempenho é uma preocupação? Mesmo se você não estiver tendo um problema agora, se crescer, terá dificuldade em determinar qual deles está sendo mais difícil e qual é a correção apropriada.

    

Answer 2

RAID é para redundância , o desempenho sai pela janela. Por exemplo, RAID 5 para ler um pedaço de dados all os discos do componente devem ser lidos, e a paridade verificada (que é mais lenta que a leitura de um único disco, os movimentos da cabeça vencidos) Não necessariamente ser sincronizado, assim você está esperando pelo maior tempo do conjunto, não apenas a média), escrever significa ler tudo, computar paridade e escrever novos dados e paridade, claramente mais lento do que apenas escrever. / p>

Sim, uma boa implementação de RAID e um sistema operacional inteligente podem mitigar muito isso (é necessário que até mesmo discos únicos sejam terrivelmente lentos em relação à RAM, portanto, qualquer sistema operacional que valha a pena faz um cache extensivo, independentemente dos discos). / p>

Sim, um SGBD inteligente armazenará dados na RAM o máximo possível (respeitando as promessas feitas em relação à consistência dos dados, resistência a falhas e assim por diante; quando necessário, esperará explicitamente que os dados estejam no disco em segurança antes de ir em).

Para qualquer DB, um RAMdisk é puro veneno ("dados explicitamente escritos em disco, portanto, seguros" não é).

    

Answer 3

Obrigado por todas as respostas. Eles foram muito úteis. Após algumas pesquisas subseqüentes, descobri que a velocidade de E / S não era o principal gargalo nesse 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 um arquivo de dados para cada núcleo de cpu. Ter mais arquivos ajuda a reduzir alguns tipos de problemas de contenção.

Alguns links sobre isso:

• link
• link
• link
• link

Answer 4

so that tempdb i/o rate is high in writes and reads

Muito pouca RAM. tempdb somente IOs quando estouram - caso contrário, o SQL Server não despeja as páginas tempdb no disco.

Assim, um disco RAM não ajudará - em vez disso, coloca mais memória.