windows 2008 r2 iis aumento do uso de memória do processo do trabalhador

Question

Eu tenho este site escrito em c #. cerca de 400-500 usuários on-line a qualquer momento. foi no Windows 2008 32 bits máquina antes e nunca nunca bloqueado / abrandou devido ao aumento do consumo de memória até que eu atualizei seu servidor para ganhar 2008 r2 64 bits.

O servidor antigo tinha apenas 4 gig ram e CPU quad core a 2ghz. site estava funcionando muito bem. desde que eu atualizei o servidor notei (2 vezes com em 10 dias) começou a comer carneiro. ontem à noite subiu para 4 GB de RAM. com resposta de aumento de ram diminui muito. Reciclar pool de aplicativos não ajuda. Eu tenho que reiniciar o processo de trabalho para recuperar.

Eu notei que isso geralmente acontece se houver erros contínuos. Como não alterei nada no código, posso afirmar que não está relacionado a vazamento de memória no código?

alguém se deparou com algo assim?

a mesma coisa acontece se eu criar erros contínuos com o asp clássico.

obrigado

    

Answer 1

Primeiro, como uma sugestão geral, a menos que seu aplicativo definitivamente precise de endereçamento de 64 bits, execute-o em um pool de aplicativos de 32 bits. Isso naturalmente restringe o uso de memória para 4 GB por processo.

Por que isso pode ser importante? Bem, porque 4GB para uma aplicação de 64 bits é um erro de arredondamento! Se o framework .NET não estiver sob pressão de memória, talvez não se preocupe com a coleta de lixo. Essa não é uma ótima resposta, e eu não sei porque esse seria o caso sob R2 e não R1, exceto pela possível resposta de tamanho de memória.

Em Reciclagem: A reciclagem deve criar um novo processo de trabalho na próxima solicitação e, por padrão, fornece a antiga até 90 segundos para ser concluída - a reciclagem faz reiniciar o processo de trabalho (ou pelo menos diz ao WAS para iniciar um novo WP na próxima vez que um pedido chegar e educadamente informar ao último WP que ele está sendo reciclado). A menos que a Reciclagem sobreposta esteja desativada, você deverá ver um novo w3wp com um novo PID assim que a próxima solicitação para esse site for recebida.

Se você ainda estiver vendo o vazamento em um pool de aplicativos de 32 bits, precisará solucioná-lo como um vazamento de memória - considere tirar um despejo de memória do processo quando está no estado de alta memória e, em seguida, na depuração com sos.dll ou psscor2.dll para encontrar o principal consumidor da memória.

    

Answer 2

Eu poderia ter encontrado o motivo. Eu não sei porque isso não aconteceu no iis7 ou 6, mas o que acontece é isso.

Isso acontece se você definir as páginas de erro iis / asp.net em uma página dinâmica, como 500.aspx, 404.aspx e o erro for site wide, de modo que cada solicitação receba o mesmo erro. Parece que, devido ao bloqueio da sessão, ele aguarda antes do término antes de processar a página de erro dinâmico e enfileira sua solicitação. como o número de pedidos aumenta a memória aumenta.