O que devo fazer para garantir que o IIS não recicle meu aplicativo?

Question

Eu tenho um aplicativo de serviço WCF hospedado no IIS. Na inicialização, ele busca um recurso muito caro (em termos de tempo e CPU) para usar como cache local.

Infelizmente, o IIS parece reciclar o processo regularmente. Portanto, estou tentando alterar as configurações do pool de aplicativos para garantir que o IIS não recicle o aplicativo. Até agora, alterei o seguinte:

• Limite o intervalo na CPU de 5 a 0.
• Tempo limite de inatividade no modelo de processo de 20 a 0.
• Intervalo de tempo regular em reciclagem de 1740 a 0.

Isso será suficiente? E tenho perguntas específicas sobre os itens que alterei:

1. O que significa especificamente a configuração Limit Interval na CPU? Isso significa que se um determinado uso da CPU for excedido, o pool de aplicativos será reciclado?
2. O que exatamente significa “reciclado”? O aplicativo foi completamente desmontado e reiniciado?
3. Qual é a diferença entre "encerramento do processo de trabalho" e "reciclagem do pool de aplicativos"? A documentação do Idle Time-out em Process Model fala sobre o encerramento do processo de trabalho. Enquanto os documentos para Intervalo de tempo regular em Reciclagem falam sobre reciclagem de pool de aplicativos. Eu não entendo bem a diferença entre os dois. Achei que w3wp.exe fosse o processo de trabalho que executa o pool de aplicativos. Alguém pode explicar a diferença de aplicação entre os dois?

A razão para ter tags IIS7 e IIS7.5 é porque o aplicativo será executado em ambos e espera que as respostas sejam as mesmas entre as versões.

Imagem para referência:

Answer 1

Reciclando

A reciclagem geralmente* é onde o IIS inicia um novo processo como um contêiner para seu aplicativo e, em seguida, permite que o antigo ShutdownTimeLimitdesapareça por vontade própria antes de ser eliminado.

*- normalmente: consulte DisallowOverlappingRotation/ configuração "Desativar reciclagem sobreposta"

Isso édestrutivo, na medida em que o processo original e todas as suas informações de estado são descartadas. Usar o estado de sessão fora do processo (por exemplo, State Server ou um banco de dados, ou até mesmo um cookie se o seu estado for pequeno) pode permitir que você resolva isso.

Mas é por padrãosobreposta- o que significa que a duração de uma interrupção é minimizada porque o novo processo é iniciado e conectado à fila de solicitações, antes que o antigo seja informado "você tem [ ShutdownTimeLimit] segundos para terminar. Por favor, cumpra."

Configurações

Para sua pergunta: todas as configurações dessa página controlam a reciclagem de alguma forma. O “desligamento” pode ser descrito como “reciclagem proativa” – onde o próprio processo decide que é hora de partir e sai de maneira ordenada.

A reciclagem reativa é onde o WAS detecta um problema e dispara o processo (após estabelecer um W3WP substituto adequado).

Agora, aqui estão algumas coisas que podem causar reciclagem de uma forma ou de outra:

• uma ISAPI decidindo que não é saudável
• qualquer módulo travando
• tempo limite ocioso
• limitação de CPU
• ajustando as propriedades do pool de aplicativos
  • como sua mãepoderiagritaram a certa altura: "Pareescolhendonisso, ou nunca vai melhorar!"
• Falha de "ping" * não é realmente ping em si, porque usa um canal nomeado - mais "detecção de vida"
• todas as configurações na imagem acima

O que fazer:

Geralmente:

• DesativarTempos limite de inatividade. 20 minutos de inatividade = bum! Processo antigo desapareceu! Novo processo na próxima solicitação recebida. Defina isso como zero.

• DesativarIntervalo de tempo normal- o padrão de 29 horas foi descrito como "insano", "irritante" e "inteligente" por várias partes. Na verdade, apenas duas delas são verdadeiras.

• OpcionalmenteLigarDisallowRotationOnConfigChange(acima,Desative o Reycling para alterações de configuração) se você simplesmente não consegue parar de brincar com ele - isso permite alterar qualquer configuração do pool de aplicativos sem sinalizar instantaneamente aos processos de trabalho que ele precisa ser eliminado. Você precisa reciclar manualmente o App Pool para que as configurações entrem em vigor, o que permite predefinir as configurações e usar uma janela de alteração para aplicá-las por meio do processo de reciclagem.

• Como princípio geral,deixarpinghabilitado. Essa é a sua rede de segurança. Já vi pessoas desligá-lo e, às vezes, o site trava indefinidamente, levando ao pânico... então, se as configurações forem muito agressivas para o seu aplicativo aparentemente muito, muito lento para responder, recue um pouco e veja o que você obtém, em vez de desligá-lo. (A menos que você tenha configurado o despejo do modo de falha automática para W3WPs travados por meio de seu próprio processo de monitoramento)

Isso é suficiente para fazer com que um processo bem comportado dure para sempre. Se morrer, claro, será substituído. Se travar, o ping deverá ser detectado e um novo deverá ser iniciado dentro de 2 minutos (por padrão; o cálculo do pior caso deve ser: atéfrequência de ping+Tempo limite de ping+limite de tempo de inicializaçãoantes que as solicitações comecem a funcionar novamente).

A limitação da CPU não énormalmenteinteressante, porque por padrão ele está desligado e também configurado para não fazer nada; se fosse configurado para encerrar o processo, claro, isso seria um gatilho de reciclagem. Deixe isso desligado. Nota para o IIS 8.x, o CPU Throttling também se torna uma opção.

Um AppPool (IIS) não é um AppDomain (.Net) (mas pode conter um/alguns)

Mas... então entramos na terra .Net e AppDomínioreciclagem, o que também pode causar perda de estado. (Ver:https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)

Versão resumida, você faz isso tocando em um arquivo web.config em sua pasta de conteúdo (novamente com a colheita!), ou criando uma pasta nessa pasta, ou um arquivo ASPX, ou.. outras coisas... e isso ésobretão destrutivo quanto uma reciclagem de App Pool,menosos custos de inicialização do código nativo (é puramente um conceito de código gerenciado (.Net), portanto, apenas coisas de inicialização de código gerenciado acontecem aqui).

O antivírus também pode acionar isso ao verificar arquivos web.config, causando uma notificação de alteração, causando....

Answer 2

Por favor, verifique,

Por que reciclamos nossos pools de aplicativos?

se você navegar na Web para descobrir o motivo pelo qual os pools de aplicativos são configurados para serem reciclados automaticamente periodicamente,você terá dificuldade em encontrar uma resposta razoável que não se refira a problemas de memória. É como se a comunidade em geral tivesse aceitado o fato de que nossas aplicações web(ou camadas de serviço hospedadas no IIS) precisarão ser recicladas para evitar problemas de memória.

Sempre fui da opinião de quese o seu código exigir reinicializações periódicas para continuar funcionando corretamente, algo está claramente errado. Há um bugno seu código em algum lugar e você precisa consertar isso, em vez de reiniciar o processo ocasionalmente para fazer o problema 'desaparecer'.

Realmente preciso começar a me concentrar mais emgerenciamento de memóriaem .NET e em garantir que nossos aplicativos possam continuar funcionando sem problemas.

Answer 3

Com base no cenário OP (inicialização longa na inicialização/aquecimento), outra coisa a verificar éLimite de tempo de inicialização(segundos) que tem um valor padrão de 90 segundos. Se a inicialização demorar mais do que o limite de tempo de inicialização, o processo de trabalho poderá ser encerrado.

Answer 4

A resposta é, vocêpodeimpedir que o AppPool seja reciclado, mas vocênão deveria.

A razão é que, se houver um vazamento de memória, ele eventualmente consumirá toda a memória do servidor e o Windows exibirá uma tela azul ou lançará exceções de falta de memória que derrubarão outros sites no mesmo servidor IIS.

Portanto, decida quanta memória esse site pode usar e defina as configurações acima para reciclar quando esse limite for atingido.

Normalmente, a reciclagem é feita normalmente, de modo que os usuários finais não estão cientes disso. Mas se você estiver usando o Blazor Server, todas as sessões serão executadas no servidor e todo o estado será perdido. Na prática, vejo um aplicativo Blazor mostrar a mensagem "conectando..." por cerca de 5 segundos enquanto ocorre a reciclagem. Em outras palavras, não é adequado para aplicativos Server Side Blazor.

A moral da história é a que foi mencionada anteriormente: certifique-se de que seu site não vaze memória. Teste sua memória no início do processo de desenvolvimento, não espere até que ele entre no ar, pois o Blazor Server consome muita memória e minha experiência é que tive que gastar um pouco de tempo depurando problemas de memória. Isso não é culpa do Blazor, é apenas da natureza dos aplicativos do Blazor Server exigir um código muito rígido. Anteriormente, no .net, nunca me preocupei com a memória, pois o GC cuidaria de tudo isso, mas rodar dentro do IIS é uma história diferente.