A menos que o processo do operador quebre um dos critérios de reciclagem configurados (o limite de bytes virtuais parece ser bom?) ou não esteja respondendo a pings, ele não é reciclado.
As aplicações (ISAPIs) podem comunicar-se como não saudáveis, o que desencadeia uma reciclagem, mas isso acontece em condições bastante restritas.
Seu aplicativo basicamente fragmenta a memória enquanto ela é executada, e a OOM reflete isso - não há memória livre e não alocada contígua disponível para novas alocações; eles falham.
Suas opções com base na descrição são:
-
corrija o padrão de alocação
-
separe as partes do aplicativo em pools de aplicativos separados (execute .Net separadamente do ASP, por exemplo) - nem todos os aplicativos podem ser divididos dessa maneira, mas é uma vitória fácil para os que podem. Dois pools de aplicativos = 2 (ou mais) processos de trabalho = 2 GB por espaço de endereço do processo de trabalho
-
implemente um limite de bytes virtuais para reciclar o pool de aplicativos quando ele ficar muito grande
-
implemente uma reciclagem diária para evitar que o aplicativo chegue ao ponto em que todo o espaço da memória é fragmentado
-
se o seu aplicativo for sem estado, experimente jardinagem na web; aumentar o número máximo de processos de trabalho para evitar falhas por mais tempo.
-
Executar como um aplicativo de 32 bits em um sistema de 64 bits; 4 GB são fornecidos para processos de trabalho.
Essencialmente, se (o que for) o heap ficar super fragmentado, você estará em uma espiral de morte nesse ponto e precisará de um novo processo de trabalho.
O IIS não tem cintos de segurança embutidos para isso, portanto, implementar um limite de reciclagem em seu processo antes que chegue a esse ponto - ou apenas dizer "esqueça isso, estou indo para 64 bits!" podem ser soluções possíveis.