Início / dba / Perguntas / 335345
Accepted
maxschaf
Asked: 2024-01-31 05:54:43 +0800 CST

Os bancos de dados OLTP na memória demoram muito para serem recuperados durante a inicialização

  • 772

usamos o SQL Server 2019 no Windows com oltp na memória ativado em alguns bancos de dados. Após a reinicialização do servidor/reinicialização do serviço, os bancos de dados na memória demoram muito para ficarem disponíveis (mais de uma hora), mesmo que a maioria das tabelas não seja durável. O tamanho dos objetos com otimização de memória é muito pequeno: 10 MB

Vemos uma sessão em segundo plano no banco de dados mestre com tipo de espera (110514580ms)WAIT_XTP_RECOVERY e quase nenhuma leitura. Os núcleos da CPU estão em 100%. Os discos estão ociosos.

Usamos criptografia transparente de dados (TDE) para este banco de dados. Este banco de dados usa sinônimos para acessar outro banco de dados na mesma instância. Ele usa corretor de serviço. A instância possui replicação transacional configurada em bancos de dados sem ativação na memória.

Adicionar CPU torna-o mais rápido. Esta é uma máquina de baixo custo, mas não uma porcaria. Motor XTP 2.11.

Alguma idéia do que está acontecendo?

sql-server

2 respostas

  1. Best Answer

    Após a reinicialização do servidor/reinicialização do serviço, os bancos de dados na memória demoram muito para ficarem disponíveis (mais de uma hora), mesmo que a maioria das tabelas não seja durável.

    Existem muitas facetas nisso além de durável ou não durável. As tabelas duráveis ​​precisarão ter seus arquivos de dados/delta lidos de volta na memória e isso levará tempo. Está demorando o tempo todo? Não sei, precisaríamos de mais dados.

    Se você tiver muitos objetos na memória (tabelas, procedimentos armazenados), todos esses objetos, independentemente do tipo, precisarão ser recompilados e carregados na memória antes que as tabelas associadas (duráveis) possam ter seus índices carregados na memória. O processo de compilação não deve demorar muito individualmente, mas pode demorar muito em conjunto. Isso não inclui coisas como software anti* que verifica o que você está fazendo 1.500 vezes e atrapalha.

    Se você observar suas estatísticas de espera, isso PREMPTIVE_OS_FINDFILEindica PREEMPTIVE_OS_CREATEDIRECTORYcontenção com o número de objetos sendo compilados e carregados no sistema - para os quais o TF 9944 desabilitará a criação de símbolos de depuração (PDBs) e arquivos de saída, entre outras otimizações. Isto pode ter um impacto substancial em sistemas com um grande número de itens otimizados para memória.

    Por último, quais são as especificações deste servidor? O que mostram os contadores de desempenho? A CPU está alta, o que indica que muitos itens e/ou software Anti* estão atingindo você (ou ambos!). Qual é a CPU? Você tem um rastreamento etw cobrindo o tempo de inicialização? Qual é a situação do VLF e do log, quanto log precisa ser lido?

    Resumo de comentários com respostas

    • PREEMPTIVE_OS_CREATEDIRECTORY é mostrado durante a maior parte do tempo de espera
    • usamos quatro núcleos de um Xeon Gold 6354 com 96 GB de memória; o armazenamento tem cerca de 20.000 E/S. VMware.
    • TF 9944 ajuda e agora temos startups rápidas
    • A compilação dos objetos na memória demorava 15 minutos em vez de duas horas agora
    • o banco de dados tem 800 objetos, mas apenas 100 são MEMORY_OPTIMIZED

    O que estou me perguntando agora é: como podemos evitar a recompilação das DLLs na inicialização?

    Você realmente não sabe, é assim que funciona atualmente no SQL Server. Compilar código pode/é caro, e é isso que está acontecendo aqui, ter apenas 4 processadores é o gargalo no momento.

    O SQL Server faz pontos de verificação implícitos no desligamento. Isso é bom o suficiente? Ou deveríamos chamar CHECKPOINTs explícitos antes do encerramento?

    Nenhum dos dados fornecidos mostra que isso é um problema.

    E quanto ao KB3147012? Experimentei configurar o TF 9929 além do TF 9944. Qual é a sua recomendação sobre isso?

    Deseja que o arquivo comece com um tamanho de arquivo baixo? Isso é o que 9929 faz, não vejo isso como seu problema.

    • 9

  2. Você precisa distribuir os arquivos de dados/delta por vários contêineres e distribuir esses contêineres por várias unidades. Seu gargalo provavelmente é causado pelo uso de uma única unidade para armazenar um único contêiner.

    • -1

relate perguntas