Limites de CPU para pools de aplicativos no IIS 7.5


8

Vejo que no iis 7.5 posso definir um limite de% de utilização da CPU por um período de tempo especificado para um pool de aplicativos. Também posso mandar matar o processo de trabalho se esse limite for violado. Se for solicitado, o processo do operador será reiniciado automaticamente após a interrupção ou será necessária intervenção manual?

Em Stack Overflow, há a menção de que ele pode ser reiniciado após a conclusão do intervalo ...

Respostas:


4

Parece um daqueles casos em que simulação (ou acesso ao código-fonte ...> suspiro <) provavelmente será a única maneira de ver qual é o comportamento com algum grau de confiança.

A documentação para a entrada do log de eventos para reciclagem de cota de CPU fala sobre reciclagem da seguinte maneira:

Por padrão, a reciclagem do pool de aplicativos é sobreposta, o que significa que o processo do operador que deve ser desligado é mantido em execução até depois que um novo processo do operador é iniciado. Depois que um novo processo de trabalho é iniciado, novas solicitações são passadas para ele. O processo de trabalho antigo é encerrado após o término do processamento de solicitações existentes ou após um tempo limite configurado, o que ocorrer primeiro. Essa forma de reciclagem garante um serviço ininterrupto aos clientes. No entanto, se um aplicativo no pool de aplicativos não puder executar mais de uma instância por vez, a rotação sobreposta poderá ser desativada.

Parece-me que, por definição, encerrar um processo de trabalho por causa do consumo excessivo de CPU significa que as solicitações pendentes não podem ser concluídas (pois estão esgotando a cota de CPU).

Para falar com sua principal preocupação: não estou vendo nada que me leve a acreditar que um novo processo de trabalho não seria gerado automaticamente. A declaração no link Stack Overflow me faz questionar se o algoritmo usado pelo IIS pode, de fato, vincular a reciclagem à resolução do timer usado para medir a exaustão da cota de CPU. A melhor maneira que eu sei para determinar isso seria escrever um componente do lado do servidor que desperdice a CPU, implantá-lo em um ambiente de teste e ver como seu comportamento de reciclagem atua. Um componente simples que fica em loop apertado por alguns segundos e depois retorna uma string conhecida, combinada com um cliente executando um equipamento de teste com algo como um conjunto de processos "wget" paralelos, pode ser suficiente.


Você parece que talvez eu precise testá-lo. Eu já escrevi um script de teste de carga única em python para testar esse tipo de coisa que foi útil ... tive que usar a versão hackeada do soquete e da biblioteca http para poder ligar-me a diferentes IPs de origem :-)
Kyle Brandt

Um pedido pode ser suficiente embora ... web aplicativo que calcula pi ...
Kyle Brandt

@ Kyle: Eu não vou fazer um pedido infinito, no entanto. Eu faria algo que, uma vez que você receba alguns pedidos "em vôo", sature a CPU do servidor, mas acabe retornando um resultado. Dessa forma, seu equipamento de teste pode informar sobre o sucesso / falha de todos os pedidos que ele faz. Caso contrário, você não tem idéia se o comportamento de reciclagem realmente resulta em uma interrupção do serviço para os clientes ou não.
Evan Anderson

Oh, entendo o que você está dizendo ... não era realmente o objetivo principal deste teste ... mas uma boa informação para ter. Eu só quero ver quando é morto, volta ou não. O limite da CPU será algo em torno de 90% por 5 minutos em algo que seria talvez de 5 a 10% de uso. Basicamente, é :-) quebrou
Kyle Brandt

Meus próprios testes mostram que a execução de um pool de aplicativos em uma atualização de 1 minuto com um limite de CPU 1 (muito pequeno), quando o limite é atingido, um Evento de Sistema 5025 é registrado e o pool de aplicativos é interrompido , interrompendo o processo w3wp. Após o término do prazo, o pool de aplicativos é reiniciado.
glasnt

4

Dados os comentários da outra resposta, eu fiz meu próprio teste, que replicarei aqui.

Nos meus testes, limitar um pool de aplicativos (v4.0 Integrated) a um pequeno limite de CPU (0,01%) e um pequeno intervalo (1 minuto) com a ação KillW3WP ativada, ultrapassar esse limite mata o w3wp interrompendo o pool de aplicativos .

Depois que o limite do intervalo é atingido, o pool de aplicativos é reiniciado automaticamente .

Alterar a ação para Nenhuma ação não altera o processo w3wp.

Nos dois casos, um evento de sistema 5025 é registrado.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.