Tempdb do SQL Server no disco RAM?

Nosso banco de dados de aplicativos de fornecedores é muito intensivo em TempDB.

O servidor é virtual (VMWare) com 40 núcleos e 768 GB de RAM, executando o SQL 2012 Enterprise SP3.

Todos os bancos de dados, incluindo o TempDB, estão no SSD de camada 1 na SAN. Temos 10 arquivos de dados tempdb, cada um pré-aumentado para 1 GB e eles nunca aumentam automaticamente. Mesmo com arquivo de log de 70 GB. Os sinalizadores de rastreamento 1117 e 1118 já estão definidos.

sys.dm_io_virtual_file_stats mostra mais de 50 Terabytes lidos / gravados em dados tempdb e arquivos de log no mês passado, com io_stall acumulado de 250 horas ou 10 dias.

Já ajustamos o código e os SPs do fornecedor nos últimos 2 anos.

Agora, estamos pensando em colocar arquivos tempdb no RAM Drive, pois temos uma tonelada de memória. Como o tempdb é destruído / recriado quando o servidor é reiniciado, é um candidato ideal para colocar na memória volátil que também é liberada quando o servidor é reiniciado.

Testei isso em um ambiente mais baixo e resultou em tempos de consulta mais rápidos, mas aumentou o uso da CPU, porque a CPU está fazendo mais trabalho em vez de aguardar na unidade tempdb lenta.

Alguém mais colocou seu tempdb na RAM em sistemas de alta produção oltp? Existe alguma grande desvantagem? Existem fornecedores para escolher ou evitar especificamente?

Primeiro, remendo: verifique se você está na Atualização Cumulativa 10 do Service Pack 1 de 2012 10 ou mais recente. No SQL 2014, a Microsoft alterou o TempDB para ficar menos ansioso para gravar em disco , e eles o trouxeram de volta para 2012 SP1 CU10 de 2012 , para aliviar muita pressão de gravação do TempDB.

Segundo, obtenha números exatos de sua latência. Verifique sys.dm_io_virtual_file_stats para ver a média de interrupção de gravação dos seus arquivos TempDB. Minha maneira favorita de fazer isso é:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

Veja a seção de estatísticas do arquivo e concentre-se nas gravações físicas. Os dados do SinceStartup podem ser um pouco enganadores, pois também incluem momentos em que o CHECKDB está em execução e isso pode realmente prejudicar o seu TempDB.

Se a latência média de gravação for superior a 3 ms, sim, você pode ter armazenamento de estado sólido na sua SAN, mas ainda não é rápido.

Considere os SSDs locais para o TempDB primeiro. Os bons SSDs locais (como as placas PCIe NVMe da Intel, que estão abaixo de US $ 2k, especialmente nos tamanhos que você descreve) têm latência extremamente baixa, mais baixa do que é possível com o armazenamento compartilhado. No entanto, na virtualização, isso traz uma desvantagem: você não pode vMotion o convidado de um host para outro para reagir ao carregamento ou a problemas de hardware.

Considere uma unidade de RAM por último. Existem duas grandes dicas com essa abordagem:

Primeiro, se você realmente possui uma atividade de gravação pesada no TempDB, a taxa de alteração na memória pode ser tão alta que você não poderá vMotion o convidado de um host para outro sem que todos percebam. Durante o vMotion, você deve copiar o conteúdo da RAM de um host para outro. Se estiver realmente mudando tão rápido, mais rápido do que você pode copiá-lo na sua rede vMotion, você pode ter problemas (especialmente se esta caixa estiver envolvida com espelhamento, AGs ou um cluster de failover).

Segundo, as unidades de RAM são software. Nos testes de carga que eu fiz, não fiquei impressionado com a velocidade deles sob atividades realmente pesadas do TempDB. Se é tão pesado que um SSD de nível empresarial não pode acompanhar, você também estará tributando o software da unidade de RAM. Você realmente desejará carregar esse teste com muita força antes de entrar no ar - tente coisas como muitas recriações simultâneas de índices em diferentes índices, todas usando o sort-in-tempdb.

Criar uma unidade de RAM deve ser trivial. Muitos pen drives e drives ópticos Linux inicializáveis ​​criam um drive de RAM e armazenam arquivos de SO lá. O sistema de arquivos raiz fica na memória. No Windows, antigamente, uma unidade de RAM era carregada como um driver de dispositivo no config.sys. Normalmente, o driver foi carregado com muita memória. Na minha opinião, esta é uma solução muito boa e simples. Se você criou sua solução usando uma unidade de RAM, eu gostaria de ouvi-la. Gostaria de fazer algo semelhante, mas gostaria de fazer gravações no armazenamento permanente e armazenar um db na RAM. No meu caso, temos máquinas que podem instalar mais RAM do que o sistema operacional pode usar. Criar um disco de RAM antes do carregamento do SO permitirá a utilização da RAM que o SO não veria de outra forma.