Gerenciamento de memória e limites do IIS com possíveis vazamentos

Question

Estamos executando alguns servidores Web X64 Win Server 2012 (Então, IIS 8).

Estamos percebendo que a memória livre nas caixas está constantemente em 5-10% livre. Na verdade, executamos muitos aplicativos nessas caixas (13 sites, 80 aplicativos em 13 pools de aplicativos). A maior parte do código é duplicada para cada site, pois corresponde a um banco de dados e um site físico diferentes, mas o aplicativo é o mesmo.

Estamos bastante confiantes de que temos um vazamento de memória no aplicativo, já que a memória continua crescendo, por isso estamos vendo isso logo de cara, mas algo em que estou confuso é a alocação de memória e o gerenciamento de IIS. Eu estou querendo saber se é diferente para servidores IIS 8 ou x64 (acabamos de nos mudar para x64 recentemente).

Então, basicamente, cada um dos nossos servidores da Web tinha 6 GB de memória e ficava com 5-10% de memória livre. O aplicativo principal que, com certeza, está vazando estava usando uma incrível memória de 1,2 gb. O próximo foi de cerca de 800MB ea média restante para cerca de 400-500MB (Todos esses valores são de memória privada, como visto no gerenciador de tarefas) Como eu disse o código é duplicado por isso, se houver um vazamento em um site será em todos eles são apenas diferentes locais físicos que podem ter alguns recursos ativados ou desativados, o que explica a grande discrepância.

Enquanto resolvemos o problema, decidimos aumentar a memória para não nos depararmos com problemas. Então ontem à noite eu derrubei cada servidor e dobrou a memória para 12GB. Esta manhã os 3 servidores estão sentados em 77%, 80% e 82% usaram memória. Todos os processos aumentaram seu uso de memória em 1,5 a 2 vezes.

Então agora estou confuso. É realmente um vazamento de memória? Ou existe algum tipo de pré-alocação de memória? Ou ele nunca libera memória, a menos que outro processo o solicite ao SQL Server ou o quê?

O que estava mantendo os níveis de memória sob controle em 6 GB se de repente eles crescem tão grandes quando a memória dobra? Existem limites que são definidos? O IIS / ASP simplesmente não coleta lixo até que a memória esteja baixa ou o que?

Qualquer resposta é apreciada.

    

Answer 1

Não se preocupe! Você pode estar apenas com excesso de cache!

A configuração padrão do cache de saída no IIS permite o armazenamento em cache no modo kernel e no modo de usuário.

O cache do modo kernel é gerenciado pelo driver HTTP nativo (também conhecido como http.sys), e é muito rápido, mas só pode servir conteúdo que seja "público", já que precisa ser capaz de responder a um cache antes do solicitação chega ao aplicativo da web.
Infelizmente, isso significa que vários tipos de solicitação não podem ser armazenados em cache no modo kernel, incluindo sessões autorizadas (como visitas a sites que exigem autenticação).

O tipo de configuração que você descreve parece com algum tipo de serviço de cliente de multilocação, levando-me a acreditar que o cache do modo kernel está fora de questão.

O cache de modo de usuário, por outro lado, é gerenciado no nível do aplicativo e os objetos armazenados em cache são armazenados no conjunto de memória do processo de operador de serviço. O tamanho total do cache é governado pelo atributo chamado maxCacheSize no elemento de configuração system.webServer/Caching .

Por padrão, o atributo maxCacheSize é definido como 0 , o que, aproximadamente, significa Permitir que o IIS aloque a quantidade de memória que atualmente é permitida .

Se você tem muitos hits pequenos consecutivos (< 256kb), mas um baixo uri cache hit ratio , o IIS certamente irá consumir toda a memória que você fornecer.

Você pode testar facilmente se isso é verdade ou não, diminuindo o valor maxCacheSize ou desativando totalmente o cache de saída no servidor.

Se você ainda estiver convencido de que você tem um problema de memória com seu aplicativo, inicie o Monitor de Desempenho e examine o objeto Contador de Desempenho "Aplicativos ASP.NET".
Selecione os contadores de GC e veja como a coleta de lixo está dispersa.

As coleções Gen0 devem representar quase todas as descartes, enquanto um grande número de coleções Gen1 e Gen2 podem indicar um problema com vidas úteis mais longas do que o necessário - que é um sintoma comum do gerenciamento de memória com falha