IIS Pools d'applications - Stop/Start vs Recycle
J'ai remarqué que dans l'une de mes applications Web de production, lorsque je recycle manuellement un pool d'applications, le processus de travail recyclé peut prendre plus de 60 secondes pour être complètement détruit, en fonction de l'observation dans le Gestionnaire des tâches. Cependant, si j'arrête complètement le pool d'applications, le processus de travail disparaît presque instantanément, dans un délai de 1 à 2 secondes.
Donc, ma question est double:
a) Pourquoi la destruction du processus prend-elle tant de temps (et plus concrètement, libère-t-elle les ressources utilisées/verrouillées par celui-ci) lorsque le pool d'applications est recyclé au lieu d'être arrêté? et
b) En supposant que j'ai arrêté le trafic d'être dirigé vers le serveur, y a-t-il une raison pour NE PAS arrêter/démarrer au lieu de recycler?
Modifier:
Pour clarifier, avant de recycler ou d'arrêter le pool d'applications, j'empêche le trafic d'être envoyé au serveur en question (le serveur est dans un cluster à charge équilibrée et je le supprime de l'équilibreur de charge). Donc, en théorie, il ne devrait y avoir aucune demande sur le site Web au moment où je fais quelque chose pour le pool d'applications.
Modifier la deuxième partie:
Après avoir lu le lien d'Igal, ce qui se passe me semble assez évident. Lorsque je recycle le pool d'applications, le nouveau processus est lancé, mais comme il n'y a pas du tout de trafic, il n'enregistre pas le nouveau processus comme fonctionnant. Il ne ferme donc pas l'ancien avant le délai imparti (90 secondes).
Fort de cette connaissance, il est clair pour moi que la fonctionnalité "Recycler" est spécifiquement destinée à être utilisée en cours de route sur un serveur actif. Par ailleurs, étant donné que je vide manuellement le trafic, je devrais plutôt utiliser stop/start.
a) En raison de Recyclage superposé . Il existe un délai pendant lequel l '"ancien" processus attend le démarrage du nouveau.
b) Non, autant que je sache.
Si je me souviens bien, un recyclage permet à toutes les demandes existantes de se terminer, puis il recyclera le pool d'applications. Un arrêt le termine simplement à l'instant exact où vous l'arrêtez.
Selon ce lien ,
Arrêt - en arrêtant un pool d’applications, vous demandez à tous les IIS processus de travail servant ce pool d’applications de fermer, Et d’empêcher le démarrage de processus de travail supplémentaires le pool d'applications est redémarré. Ceci déclenche un arrêt gracieux Des processus de travail, chaque processus de travail tentant De drainer toutes ses demandes, puis de se fermer.
Si un processus de travail ne se ferme pas dans le délai spécifié Par la propriété de configuration shutdownTimeLimit dans l'élément processModel De la définition de chaque pool d'applications (valeur par défaut: 90 s), WAS le mettra fin avec force (cela ne se produira pas si un débogueur natif est attaché).
Par conséquent, l'arrêt d'un pool d'applications est une action perturbatrice qui Entraîne le déchargement des domaines d'application ASP.NET, des processus enfants FastCGI, Et la perte de tout état d'application en cours de traitement.
Recyclage - Le recyclage d'un pool d'applications entraîne la fermeture harmonieuse de tous les processus de travail en cours d'exécution IIS dans ce pool d'applications , Mais contrairement à l'arrêt du pool, le nouveau IIS Les processus de travail peuvent être lancés à la demande pour traiter les demandes suivantes.
Recycler un pool d’applications est un bon moyen de provoquer la réinitialisation de l’état de l’application Et de toute configuration mise en cache par les processus IIS worker Qui ne sont pas automatiquement actualisés (généralement clés de registre), sans perturber le fonctionnement du serveur. Ce Fait du recyclage du pool d’applications une excellente alternative à un IISRESET dans la plupart des cas.