Ajuda na solução de problemas SqlException:o tempo limite expirou na conexão, em uma situação de não carregamento

Memória insuficiente

Possibilidades fáceis de verificar:

1. 
   Você pode ter "Auto Close" ativado:Auto Close pode ter exatamente esse comportamento, porém é raro que ele seja ativado. Para verificar isso, no SSMS, clique com o botão direito do mouse no banco de dados do aplicativo, selecione "Propriedades" e, em seguida, selecione o painel "Opções". Olhe para a entrada "Auto Close" e certifique-se de que está definida como False. Verifique tempdb também.
   
2. 
   Os trabalhos do SQL Agent podem estar causando isso:Verifique o log de histórico do agente para ver se houve algum trabalho em execução consistente durante os eventos. Lembre-se de verificar também os trabalhos de manutenção, pois coisas como Reconstruir Índices são frequentemente citadas como problemas de desempenho enquanto estão em execução. Esses são candidatos improváveis ​​agora, apenas porque normalmente não seriam afetados pelo Profiler.
   

Por que parece um problema de memória:

• 
  Você tem 1 GB de memória:embora tecnicamente esteja acima do mínimo para o SQL Server, está muito abaixo do recomendado para o SQL Server e muito abaixo do que, na minha experiência, é aceitável para produção, mesmo para um servidor pouco carregado.
  
• 
  Você está executando o IIS e o SQL Server na mesma caixa:Isso não é recomendado por si só, em grande parte devido à contenção de memória que resulta, mas com apenas 1 GB de memória resulta no IIS, no aplicativo, no SQL Server, no SO e quaisquer outras tarefas e/ou manutenção, todos lutando por muito pouca memória. A maneira como o Windows gerencia isso é fornecer memória aos processos ativos, retirando-a agressivamente dos processos não ativos. Pode levar muitos segundos ou até minutos para um processo grande como o SQL Server recuperar memória suficiente para poder atender completamente a uma solicitação nessa situação.
  
• 
  O Profiler fez 90% do problema desaparecer:Esta é uma grande pista de que a memória é provavelmente o problema, porque normalmente, coisas como o Profiler têm exatamente esse efeito sobre esse problema específico:a tarefa do Profiler mantém o SQL Server apenas um pouco pouco ativo o tempo todo. Freqüentemente, isso é atividade suficiente para mantê-lo fora da lista de "limpadores" do sistema operacional ou, pelo menos, reduzir um pouco o impacto.
  

Como verificar a memória como o culpado:

1. 
   Desligue o Profiler:Está tendo um efeito Heisenberg no problema, então você tem que desligá-lo ou você não poderá ver o problema de forma confiável.
   
2. 
   Execute um Monitor do Sistema (perfmon.exe) de outra caixa, que se conecta remotamente ao serviço de coleta de desempenho na caixa em que o SQL Server e o IIS estão sendo executados. você pode fazer isso mais facilmente removendo primeiro as três estatísticas padrão (elas são apenas locais) e, em seguida, adicione as estatísticas necessárias (abaixo), mas certifique-se de alterar o nome do computador no primeiro menu suspenso para se conectar ao seu SQL caixa.
   
3. 
   Envie os dados coletados para um arquivo criando um "Counter Log" no perfmon. Se você não estiver familiarizado com isso, provavelmente a coisa mais fácil a fazer é coletar os dados em uma guia ou arquivo separado por vírgula que você pode abrir com o Excel para analisar.
   
4. 
   Configure seu perfmon para coletar em um arquivo e adicione os seguintes contadores a ele:
   
   -- Processador\%Tempo do Processador[Total]
   
   -- PhysicalDisk\% Idle Time[para cada disco ]
   
   -- Disco Físico\Avg. Comprimento da fila de disco[para cada disco ]
   
   -- Memória\Páginas/s
   
   -- Memória\Leituras de Páginas/s
   
   -- Memória\MBytes Disponíveis
   
   -- Interface de rede\Total de bytes/s[para cada interface em uso ]
   
   -- Process\% Processor Time[veja abaixo ]
   
   -- Processo\Falhas de página/s[veja abaixo ]
   
   -- Processo\Conjunto de Trabalho [veja abaixo ]
   
5. 
   Para os contadores de processo (acima), você deseja incluir o processo sqlserver.exe, quaisquer processos do IIS e quaisquer processos de aplicativos estáveis. Observe que isso funcionará SOMENTE para processos "estáveis". Processos que estão sendo recriados continuamente conforme necessário, não podem ser capturados dessa maneira porque não há como especificá-los antes que eles existam.
   
6. 
   Execute essa coleção em um arquivo durante o horário em que o problema ocorre com mais frequência. Defina o intervalo de coleta para algo próximo de 10 a 15 segundos. (isso coleta muitos dados, mas você precisará dessa resolução para escolher os eventos separados).
   
7. 
   Depois de ter um ou mais incidentes, interrompa a coleta e abra seu arquivo de dados coletados com o Excel. Você provavelmente terá que reformatar a coluna de carimbo de data/hora para ficar visível de forma útil e mostrar horas, minutos e segundos. Use o log do IIS para encontrar a hora exata dos incidentes e, em seguida, examine os dados de desempenho para ver o que estava acontecendo antes e depois do incidente. Em particular, você quer ver se seu conjunto de trabalho era pequeno antes e grande depois, com muitas falhas de página no meio. Esse é o sinal mais claro desse problema.
   

SOLUÇÕES:

E aquela coisa estranha da EF?