ASP.NET app comendo memória. Application / Session objetos o motivo?

Question

Portanto, estamos testando o estresse de um aplicativo ASP.NET desenvolvido por uma empresa externa. Estamos fazendo aproximadamente 50 solicitações por segundo e, após cerca de meia hora, cada um dos 48 processos de trabalho (w3wp.exe) tem até 400 MB e conta. Executando no IIS7.

Agora, depois de me intrometer com o dotTrace, estou bastante certo de que há um vazamento de memória aqui, mas é difícil ter 100% de certeza sem conhecer o aplicativo. Quando confrontamos os desenvolvedores com essa teoria, eles descartaram após 30 segundos dizer algo como "a memória é manipulada automaticamente no .NET". Certamente, o .NET teria o lixo coletado 48x ~ 400MB se os dados fossem finalizados?

De qualquer forma, estou acostumado a trabalhar com o WinForms. Como exatamente alguém cria vazamentos de memória no ASP.NET? É a única maneira (mis) usando os objetos de aplicativo e sessão no .net?

editar

Desde que publiquei esta questão, aprendi que manter referências estáticas a objetos nos manipuladores de solicitação (seja uma classe de serviço da Web, um formulário da web ou qualquer outro) causará "vazamentos". Provavelmente não é o termo correto aqui, mas de qualquer forma ... Isso eu não tinha certeza, porque eu pensei que as classes manipuladoras foram mortas e recriadas após cada solicitação pelo IIS.

Portanto, codifique como este:

public class SomeService : IService
{
    public static List<RequestData> _requestDataHistory = new List<RequestData>();
    public void SomeRequest(RequestData data)
    { 
        _requestDataHistory.Add(data);
    }        
}

Craseará seu servidor mais cedo ou mais tarde. Talvez isso fosse óbvio para a maioria das pessoas, mas não para mim :-)

Ainda não tem certeza se isso seria um problema se você removesse a palavra-chave estática. As instâncias são descartadas após cada solicitação?

    

Answer 1

Os desenvolvedores podem estar certos. No mundo do .Net, coleta de lixo e liberação de memória acontecem quando necessário. Ou seja se houver bastante memória disponível para o aplicativo, ela poderá consumir mais e mais, até que o sistema operacional não permita mais alocação. Você não deve se preocupar com isso, a menos que realmente cause problemas.

Naturalmente, pode haver vazamentos de memória, se o aplicativo não descartar corretamente recursos não gerenciados, como soquetes, manipuladores de arquivos, etc. Observe os objetos do sistema operacional (no gerenciador de tarefas, é possível habilitar as colunas handles e objetos do usuário) para ver como eles crescem.

Como você afirmou, o uso incorreto do objeto da Aplicação ou da Sessão também pode ser uma causa.

Estou me perguntando por que você teria 48 pools de aplicativos (processos de trabalho). Isso é um exagero e você não precisa disso.

O GC gerencia a memória por processo e 400 MB por processo não é muito. Reduza o número de pools de aplicativos para o nr. de núcleos - 1 e, em seguida, teste de estresse no aplicativo. Se, então, crescer muito, você pode se preocupar com vazamentos de memória.

Com base em suas informações adicionais, sim, nesse caso, a lista de histórico crescerá indefinidamente. Objetos estáticos são criados uma vez por domínio de aplicativo e residem até que o appdomain viva.

Eu não aconselho você a remover arbitrariamente a palavra-chave estática, a menos que você saiba que não quebra a lógica de alguma aplicação. Investigue por que esses dados são coletados de qualquer maneira e para que são usados. O código também tem outro problema - ele não é thread-safe, seu comportamento é indefinido quando dois pedidos chegam ao mesmo tempo e decide adicionar dados a essa lista.

É melhor mover sua pergunta para stackoverflow.com, pois é uma questão de programação e não administrativa.

Se você não estiver controlando esse código e realmente quiser apenas resolver seu problema de memória, poderá configurar seus apps para reciclar após um número X de solicitações, ou depois que eles obtiverem mais do que a quantidade de memória Y, mas novamente isso não é uma solução real.

    

Answer 2

Vazamentos de memória, no sentido geral, são os resultados negativos / imprevistos da lógica de codificação que não está liberando seus recursos não utilizados (ou não mais usados) corretamente (ou de todo) enquanto ainda reserva recursos adicionais para uso novo / contínuo / requisitos de processamento. A "pegada" global de recursos, então, continua a crescer, mesmo com as necessidades reais, que podem não necessariamente aumentar, se a "limpeza" apropriada de recursos e recursos de uso correto estiver em vigor.

Em suma, não se limita à programação lógica "abuso", onde pode ser a partir de suposições incorretas de gerenciamento de recursos ou apenas a falta dele.