Por que são necessárias reinicializações periódicas para manter o desempenho da minha instância?

Temos um servidor de banco de dados de produção no SQL 2005. Tudo funciona normalmente por um tempo, mas depois de algumas semanas, vemos uma queda notável no desempenho. Somente reiniciar o SQL Server traz o desempenho de volta ao normal.

Alguns antecedentes:

• Executando mais de 1200 bancos de dados (principalmente inquilino único, alguns multilocatário). Antes de alguém dar uma palestra sobre como mudar para somente multi-inquilino, há razões válidas para manter essa estrutura ......
• RAM é de 16 GB. Após reiniciar, o SQL Server não demora muito para voltar ao uso de 15 GB.
• As conexões do banco de dados ativo têm cerca de 80 conexões - o que consideramos razoavelmente íntegro, considerando que há um pool de conexões por servidor web por processo -, portanto, não temos um problema de vazamento de conexão.

Tentamos várias coisas fora do horário de pico: - Execute DBCC DROPCLEANBUFFERS (com um CHECKPOINT) para limpar o cache de dados. Não tem efeito, nem apaga nenhum uso da RAM). - Execute o FREEPROCCACHE e o FREESYSTEMCACHE para limpar os planos de consulta e o cache de proc armazenado. Sem efeito

Obviamente, reiniciar o SQL Server não é ideal em um ambiente de produção ativo. Estamos perdendo alguma coisa. Alguém mais passou por isso?

UPDATE: April-28-2012 Ainda lutando contra esse problema. Reduzi a memória do SQL Server para 10 GB, apenas para descartar qualquer disputa com o sistema operacional. Estou chegando perto de reduzi-lo, mas preciso de ajuda do meu próximo passo.

Aqui está o que eu descobri, depois de reiniciar o SQL Server, o arquivo de paginação fica entre 12,3 GB e 12,5 GB. Vai ficar assim por dias. O total de threads do servidor fica entre 850 e 930 - também estável e consistente por dias a fio (o sqlserver está entre 55 e 85 deles, dependendo do tráfego).

Então, há "um evento". Não tenho idéia do que é o evento, não consigo vê-lo nos logs e não consigo ver nada consistente no dia da semana ou no horário em que ocorre, mas todo o arquivo de paginação suddent salta para 14.1 ou 14.2 GB e os threads saltam para entre 1750 e 1785.

Verificando o desempenho quando isso acontece, mais de 900 desses threads são sqlserver. Então eu vou ao sp_who2 para ver de onde vêm esses threads ... e há apenas as conexões db de 80 ou mais usadas.

Então .... alguém tem alguma idéia de como posso localizar onde está o restante desses 900 threads no SQL server e o que eles estão fazendo?

ATUALIZAÇÃO: junho-01-2012 Ainda lutando contra o problema. Para quem ainda está lendo isso, o problema com os threads subindo foi resolvido. Isso foi causado pelo software de backup ComVault autodated. Ele estava criando um encadeamento tentando fazer backup de bancos de dados que não estavam mais lá (estava mantendo uma lista de bancos de dados anteriores), em vez de apenas fazer backup dos bancos de dados atuais.

Mas - o problema ainda permanece, e temos que reiniciar toda semana, mais ou menos alguns dias. Trabalhando com a equipe da Rackspace para ver se eles conseguem lançar alguma luz.

Você diz que está tudo bem e, depois de algumas semanas, o desempenho cai. (Geralmente, as pessoas afirmam que o desempenho diminui rapidamente, ou em horários específicos ou em intervalos aparentemente aleatórios. Isso pode significar desempenho ruim de E / S ou bloquear tempestades ou consultas intensivas na CPU, executadas em horários estranhos, ou um trabalho agendado pesado ou a falta de indexação ou estatísticas ruins que causam consultas intensivas na CPU ou leituras de disco ou outras coisas.) Semanas é incomum.

Minha hipótese é que outro aplicativo no seu servidor esteja vazando memória. Eu já vi isso com software antivírus (todo vilão de software servidor favorito de todos os DBAs) e software de monitoramento de terceiros. Eu checava o uso de memória do SQL Server, com o tempo, e pegava todo o uso de memória de todos os outros aplicativos da caixa também. Se você tiver limites rígidos definidos para o uso da memória do SQL Server e definido para não permitir paginação, talvez outros aplicativos estejam sendo paginados e consumindo a capacidade de E / S.

Não é difícil procurar. Se você ainda não está mantendo métricas no servidor, inicio o Perfmon e peça uma amostra a cada 30 ou 60 minutos. Depois de alguns dias, você poderá ver o uso de memória de outros aplicativos subindo.

Existem mensagens de erro no log do SQL Server informando que "partes significativas do servidor sql foram paginadas"? Isso também seria uma grande pista.

Deixe-me parabenizá-lo por poder executar 1200 DBs em uma única instância do SQL Server com apenas 16 GB de RAM e ter apenas esse tipo de problema após algumas semanas de execução suave. Bela história para contar no capítulo local do PASS.

Agora, para solucionar problemas: sua RAM é de 16 GB para o SQL e o SO. Suponho que sua configuração de memória máxima seja de 15 GB ou máx. Isso pode estar fazendo com que o buffer pool use toda a memória e sufoque o sistema operacional. Você está dizendo que a limpeza do buffer pool e dos caches não está mostrando nenhuma diferença, além de seu PLE estar acima de 300. Isso atesta contra os gargalos das garrafas de memória. Como estão a CPU e o IO no servidor (especificações / estatísticas)?

Execute select * from sys.dm_exec_request where session_id>50 and session_id<>@@spide quais são as contenções de recursos que você vê (wait_type, wait_time, last_wait_type, wait_resource).

1200 bancos de dados, um sistema operacional e possivelmente outras coisas? Sim, acho que o próprio servidor precisará de mais de 1 GB de RAM para funcionar, especialmente considerando que, se você definir 15 GB como a configuração de memória máxima do SQL Server, ele ainda precisará de memória adicional fora desses 15 GB para threads.

Eu aumentaria o SQL Server para 14gb para dar ao servidor um pouco mais de espaço para respirar.

Além disso, um exemplo fornecido em "Informações e soluções de problemas profissionais do SQL Server 2008" para permissões de memória em um sistema SQL Server 2008 x64 com utilitário de backup de terceiros com 16 GB de RAM:

• 2 GB para Windows
• 1 GB para threads de trabalho
• 1 GB para MPAs, etc.
• 1 GB para o programa de backup
• 11GB para SQL Server

No livro, mostra como determinar o número máximo de threads que você pode ter e como calcular a quantidade de memória que eles ocuparão. Execute isso (altere o tipo de servidor para corresponder ao seu servidor) para descobrir quanta memória seus encadeamentos precisarão.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Se a memória do banco de dados estiver distribuída igualmente em todos os bancos de dados, você terá apenas 12,8 Megs para cada banco de dados (15 * 1024) /1200=12,8. Você precisa de mais memória.

Você precisa analisar por que o desempenho está diminuindo. Você está vendo bloqueio, bloqueio, etc? Como são as estatísticas de espera?

Os comandos DBCC apenas limparão os buffers de memória e não liberarão a memória de volta ao sistema operacional.

Você sabia que o SQL Server está realmente consumindo a memória? Sugiro analisar a configuração da sessão do Perfmon ou começar a coletar informações do DMV após uma reinicialização para descobrir o que o SQL Server está fazendo e trabalhando. Observe também se os usuários estão fazendo mais trabalho do que o normal durante o tempo de coleta (como processamento de final de mês, etc.). Você está executando o SSRS, SSIS ou SSAS no mesmo servidor?

Você possui 1200 bancos de dados no sistema, qual é o maior tamanho de banco de dados existente?