Limites du processeur pour les pools d'applications dans IIS 7.5


8

Je vois que dans iis 7.5, je peux définir une limite d'utilisation du CPU% pour une durée spécifiée pour un pool d'applications. Je peux également lui faire tuer le processus de travail si cette limite est violée. Si vous lui demandez de le faire, le processus de travail redémarrera-t-il automatiquement après sa mort ou une intervention manuelle est-elle requise?

Plus à Stack Overflow, il est mentionné qu'il peut redémarrer à la fin de l'intervalle ...

Réponses:


4

Cela ressemble à l'un de ces cas où la simulation (ou l'accès au code source ...> soupir <) sera probablement le seul moyen de voir quel est le comportement avec un certain degré de confiance.

La documentation de l' entrée du journal des événements pour le recyclage des quotas de CPU parle de recyclage comme suit:

Par défaut, le recyclage du pool d'applications se chevauche, ce qui signifie que le processus de travail qui doit être arrêté est exécuté jusqu'à ce qu'un nouveau processus de travail soit démarré. Après le démarrage d'un nouveau processus de travail, de nouvelles demandes lui sont transmises. L'ancien processus de travail s'arrête une fois qu'il a fini de traiter ses demandes existantes ou après un délai configuré, selon la première éventualité. Ce mode de recyclage assure un service ininterrompu aux clients. Toutefois, si une application du pool d'applications ne peut pas exécuter plusieurs instances à la fois, la rotation qui se chevauche peut être désactivée.

Il me semble que, par définition, la fin d'un processus de travail en raison d'une consommation excessive de CPU signifierait que les demandes en attente ne seraient pas autorisées à être terminées (car elles épuisent le quota de CPU).

Pour parler de votre principale préoccupation: je ne vois rien qui me porte à croire qu'un nouveau processus de travail ne serait pas automatiquement lancé. L'instruction dans votre lien Stack Overflow me fait me demander si l'algorithme utilisé par IIS peut, en fait, lier le recyclage à la résolution du temporisateur utilisé pour mesurer l'épuisement des quotas de CPU. La meilleure façon que je connaisse pour déterminer ce serait d'écrire un composant côté serveur gaspillant le processeur, de le déployer dans un environnement de test et de voir comment son comportement de recyclage agit. Un simple composant qui reste en boucle pendant quelques secondes puis renvoie une chaîne connue, combiné avec un client exécutant un faisceau de test avec quelque chose comme un pool de processus "wget" parallèles peut suffire.


Ya semble que je devrais juste le tester. J'ai déjà écrit un script de test à chargement unique en python pour tester ce genre de chose qui est utile ... j'ai dû utiliser une version piratée de socket et de la bibliothèque http pour que je puisse me lier à différentes IP source :-)
Kyle Brandt

Une demande pourrait cependant suffire ... application web qui calcule les pi ...
Kyle Brandt

@Kyle: Je ne ferai cependant pas de demande infinie. Je ferais quelque chose qui, une fois que vous obtenez quelques demandes "en vol", sature le processeur du serveur mais renvoie finalement un résultat. De cette façon, votre banc d'essai peut signaler le succès / l'échec de toutes les demandes qu'il fait. Sinon, vous ne savez pas si le comportement de recyclage entraîne ou non une interruption de service pour les clients.
Evan Anderson

Oh je vois ce que vous dites ... n'était pas vraiment l'objectif principal de ce test ... mais une bonne info à avoir. Je veux juste voir quand il est tué, s'il revient ou non. La limite du processeur sera d'environ 90% pendant 5 minutes sur quelque chose qui représenterait peut-être 5 à 10% d'utilisation. Fondamentalement, il est cassé :-)
Kyle Brandt

Mes propres tests montrent que l'exécution d'un pool d'applications lors d'une actualisation d'une minute avec une limite d'UC de 1 (très petite), lorsque la limite est atteinte, un événement système 5025 est enregistré et le pool d'applications est arrêté , tuant le processus w3wp. Une fois le délai expiré, le pool d'applications est redémarré.
glasnt le

4

Compte tenu des commentaires dans l'autre réponse, j'ai fait mes propres tests, que je reproduirai ici.

Lors de mes tests, la limitation d'un pool d'applications (v4.0 Integrated) à une petite limite de processeur (0,01%) et à un petit intervalle (1 minute) avec l' action KillW3WP activée, le dépassement de cette limite tue le w3wp en arrêtant le pool d'applications .

Une fois la limite d'intervalle atteinte, le pool d'applications est automatiquement redémarré .

Changer l'action en Aucune action ne modifie pas le processus w3wp.

Dans les deux cas, un événement système 5025 est enregistré.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.