Uma vez por semana, meu servidor MSSQL está expirando, ou melhor, a máquina fica sem RAM. Esta manhã chegou a 3,9 GB dos 4 disponíveis, com o MSSQL ocupando 2,5 GB.
Estou preocupado por não ter configurado o SQL para liberar memória como deveria, então executei sp_who2 enquanto os tempos limite estavam ocorrendo para ver qual processo estava sendo executado.
Se eu pudesse postar o arquivo de dados CSV, no entanto, haveria 85 processos no total, principalmente relacionados ao serviço de Texto Completo:
FT Gatherer - Cerca de 35 dessas operações na conta 'sa' do banco de dados principal com status de inativo ou plano de fundo, muitas dependiam de outros processos. Isso é normal?
Banco de dados MySite - Havia apenas 5 processos para o site / banco de dados ativo e todos estavam suspensos ou suspensos - mas as datas do lastBatch estavam definidas como 1/12/2020. Isso é normal?
A base de dados tem apenas cerca de 20mb de tamanho, os níveis de tráfego são muito baixos, por isso estou pensando em limitar a quantidade de RAM que a SQL tem acesso (de ilimitado a talvez 2GB).
Quaisquer pensamentos / conselhos seriam apreciados.
Minhas graças
Ben
Você deve sempre configurar o SQL com um limite superior, caso contrário, ele ocupará toda a memória disponível. Com 4 Gigs de RAM e apenas um banco de dados de 20 Meg definindo o limite de memória para 2 Gigs deve ser mais que suficiente.
Você está usando texto completo para qualquer coisa?
O log de eventos do sistema indica erros quando isso está acontecendo?
O log do SQL indica deadlocks ou qualquer outro motivo possível para o tempo limite?
Tem certeza de que é um problema com o SQL e não causado por outra coisa sendo executada no servidor (intencional ou não)?
Tente isso. Instale as ferramentas de depuração para o Windows. Inicie o windbg.exe no console e deixe-o em execução. Você precisaria selecionar File > Depuração do Kernel > Guia local. Na próxima ocorrência, insira o comando! Vm, que fornecerá uma imagem completa de todo o uso de memória no servidor.
Você está no x86 e usando a opção / 3GB no boot.ini? Neste cenário em uma arquitetura x86 de 32 bits, você está predisposto a pressão adicional na memória do kernel (pools paginados / não paginados, PTEs do sistema e cache do sistema de arquivos), já que / 3GB só deixa 1 GB para o SO.
No x86, quando você rodar! vm, você verá algo assim:
NonPagedPool Max: 65281 ( 261124 Kb)
PagedPool Maximum: 134144 ( 536576 Kb)
Esses números podem variar conforme são definidos dinamicamente na inicialização. Quando você tem uma ocorrência, você pode comparar o uso ao máximo para determinar se é um problema de memória do kernel.
Tags timeout sql-server