Temos o IIS em execução em dois servidores (IIS8 e 10) e recentemente encontramos um uso de memória muito alto de nossos aplicativos ASP.NET WebForms, acessados principalmente por meio de páginas aspx.
O que acontece é que com o tempo, nossos pools de aplicativos consomem cada vez mais memória, até que a memória física do servidor (64 GB) esteja quase esgotada. Definitivamente isso não é normal.
Tentamos descobrir por que isso acontece, mas estamos sem ideias. Não está claro se isso é um vazamento de memória em nosso aplicativo ou comportamento normal, então talvez alguém possa esclarecer isso.
Fatos:
Com o tempo, os pools de aplicativos reservam E usam cada vez mais memória, que não é liberada (o gerenciador de tarefas diz que tanto o conjunto de trabalho quanto o tamanho do commit são muito altos, então ele é realmente usado/mantido, certo?)
criadores de perfil de memória como ANTS, .dotMemory, .NET MemoryProfiler dizem que o consumo de memória gerenciada é bastante baixo, digamos 20-200 MB, e mostra muita memória não gerenciada, que seria usada, mas livre.
eles não dão nenhuma dica sobre o que pode estar causando o uso não gerenciado, mesmo com instantâneos e métodos de criação de perfil detalhados.
se "martelarmos" a página inicial com a tecla F5 sem soltá-la, podemos aumentar o uso de memória de 2 a 5 gigabytes em um minuto. Isso é um pouco insano.
sabemos que os pools de IIS/aplicativos tendem a reservar memória de maneira oportunista quanto mais memória estiver disponível, mas isso é demais.
a única coisa que vemos é que a primeira página parece ser mantida na memória com seus controles e objetos ComponentModel, mas não há nenhuma referência única a nenhum de nossos objetos de página ou classes de namespace próprias em qualquer lugar nos criadores de perfil de memória.
o consumo de memória era bom há um ano e parou em 2 a 3 gigabytes no total, mas não podemos mais reproduzi-lo com uma versão antiga do aplicativo.
isso também acontece em uma nova instalação local do IIS no WIN10.
os aplicativos são construídos em modo de lançamento, otimizados, compilados em uma única DLL no momento, também testados sem, sinalizador de rastreamento ativado, 5 MB de tamanho
Parece que precisamos desmontar a aplicação, dividi-la em vários módulos e ver como eles se comportam. Os assemblies/bibliotecas carregados em tempo de execução podem, mas não devem ser o problema. Na verdade, não fazemos muitas referências (FreeTextBox, Microsoft ReportViewer, SharpCompress, Crystal Reports, AjaxControlToolKit 15), já removemos tudo, exceto CrystalReports/AjaxControlToolKit para ver o que acontece, mas não mudamos.
Também usamos muitos controles WebForms, incluindo Timers e UpdatePanels às vezes.
Também não sabemos como encontrar o culpado usando memoryprofilers, supondo que haja uma referência oculta que faz com que uma ou mais páginas aspx sejam mantidas na memória porque as instâncias da classe .NET nunca mostram nenhum link para nada.
Ficaríamos felizes em receber QUALQUER dica sobre o que podemos entender mal em relação à reserva de memória ou como solucionar esse problema de consumo de memória.
Muito obrigado pelo seu tempo!
EDIT (esqueci de mencionar): - Adicionamos GC.Collect/WaitForPendingFinalizers/GC.Collect à nossa função Page_Load da página inicial para ver se ajuda, e de fato ajuda por um tempo ou um pouco, até que haja outra pressão situação (com F5) onde o uso de memória aumenta novamente de forma extrema.
Responder1
Quando GC.WaitForPendingFinalizers ajuda, pode ser um sinal de memória usada pelos threads. Se você iniciar um novo thread separado em page_load, ele poderá usar muita memória. Comece a diagnosticar o problema verificando a contagem de threads no gerenciador de tarefas.