Nosso banco de dados de aplicativos de fornecedores é muito intensivo em TempDB.
O servidor é virtual (VMWare) com 40 núcleos e 768GB de RAM, rodando SQL 2012 Enterprise SP3.
Todos os bancos de dados, incluindo o TempDB, estão no SSD Tier 1 na SAN. Temos 10 arquivos de dados tempdb, cada um pré-crescido para 1 GB e eles nunca crescem 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 cumulativo de 250 horas ou 10 dias.
Já ajustamos o código do fornecedor e os SPs nos últimos 2 anos.
Agora, estamos pensando em colocar arquivos tempdb na unidade de RAM, pois temos uma tonelada de memória. Como o tempdb é destruído/recriado quando o servidor é reinicializado, é um candidato ideal para ser colocado na memória volátil, que também é eliminada quando o servidor é reinicializado.
Eu testei isso em um ambiente inferior e resultou em tempos de consulta mais rápidos, mas aumentou o uso da CPU, porque a CPU está trabalhando mais em vez de esperar na unidade tempdb lenta.
Alguém mais colocou seu tempdb na RAM em sistemas de produção de alta oltp? Existe alguma grande desvantagem? Existem fornecedores para escolher ou evitar especificamente?
Primeiro, patch: verifique se você está no 2012 Service Pack 1 Cumulative Update 10 ou mais recente. No SQL 2014, a Microsoft alterou o TempDB para ser menos ansioso para gravar em disco e eles o portaram de forma incrível para 2012 SP1 CU10 , para que possa aliviar muita pressão de gravação do TempDB.
Em segundo lugar, obtenha números exatos de sua latência. Verifique sys.dm_io_virtual_file_stats para ver a parada média de gravação para seus arquivos TempDB. Minha maneira favorita de fazer isso é:
Veja a seção de estatísticas do arquivo e concentre-se nas gravações físicas. Os dados SinceStartup podem ser um pouco enganosos, pois também incluem horários em que CHECKDB está em execução e isso pode realmente prejudicar 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 em sua SAN, mas ainda não é rápido.
Considere SSDs locais para TempDB primeiro. Bons SSDs locais (como os cartões PCIe NVMe da Intel, que custam menos de $ 2.000, especialmente nos tamanhos que você está descrevendo) têm latência extremamente baixa, menor do que você pode obter com armazenamento compartilhado. No entanto, na virtualização, isso vem com uma desvantagem: você não pode vMotion o convidado de um host para outro para reagir à carga ou a problemas de hardware.
Considere uma unidade de RAM por último. Existem duas grandes armadilhas com essa abordagem:
Primeiro, se você realmente tiver uma atividade intensa de gravação no TempDB, a taxa de alteração na memória pode ser tão alta que você não conseguirá fazer o vMotion do 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 está realmente mudando tão rápido, mais rápido do que você pode copiá-lo em sua rede vMotion, você pode ter problemas (especialmente se esta caixa estiver envolvida com espelhamento, AGs ou um cluster de failover).
Em segundo lugar, as unidades de RAM são software. No teste de carga que fiz, não fiquei muito impressionado com a velocidade deles sob atividade realmente intensa do TempDB. Se for tão pesado que um SSD de nível empresarial não consegue acompanhar, você também estará sobrecarregando o software da unidade de RAM. Você realmente vai querer fazer um teste de carga pesado antes de ir ao ar - tente coisas como muitas reconstruções simultâneas de índices em diferentes índices, todos usando sort-in-tempdb.
Criar uma unidade de RAM deve ser trivial. Muitos pen drives e unidades ópticas inicializáveis do Linux criam uma unidade de RAM e armazenam os arquivos do sistema operacional lá. O sistema de arquivos raiz está então na memória. No Windows, antigamente, uma unidade de RAM era carregada como um driver de dispositivo em 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, gostaria de ouvi-la. Eu gostaria de fazer algo semelhante, mas gostaria de gravar no armazenamento permanente e armazenar um banco de dados na RAM. No meu caso, temos máquinas que podem instalar mais RAM do que o sistema operacional pode usar. A criação de um disco RAM antes do carregamento do sistema operacional permitirá a utilização da RAM que o sistema operacional não veria de outra forma.