Pourquoi le processus de travail IIS recycle-t-il toutes les 29 heures et non toutes les 24 heures?


24

Lorsque vous configurez un site sur IIS, le processus de travail est recyclé par défaut toutes les 1740 minutes (29 heures). Pourquoi un nombre impair comme 29 heures et non, par exemple, 24 ou 48 heures?

Réponses:


27

À Tech Ed 2003, le présentateur a posé cette question, et la réponse était qu'ils voulaient un cycle irrégulier pour l'empêcher de se produire sur une frontière quotidienne (par exemple pour se distinguer des autres tâches quotidiennes planifiées sur le serveur / domaine).

Le site ici (lien mort) a spéculé:

... (29 est le) premier premier après 24, ce qui lui permet d'avoir le moins de chance de se produire de façon régulière avec tout autre processus serveur; faciliter l'enquête sur les problèmes

Un autre site semble le confirmer:

( Wade Hilmo ) a suggéré 29 heures pour la simple raison qu'il s'agit du plus petit nombre premier supérieur à 24. Il voulait un schéma décalé et non répétitif qui ne se produise pas plus d'une fois par jour.


Intéressant. Personnellement, je pense qu'avoir quelque chose qui se reproduit à la même heure chaque jour faciliterait le suivi si le recyclage du processus de travail causait d'autres problèmes. Par exemple, le suivi d'un problème qui se produit environ tous les jours est difficile, mais il est plus facile s'il se produit à 19 heures tous les jours, car vous pouvez rechercher dans le système des événements qui se produisent à ce moment-là. Je sais que vous pouvez configurer IIS pour recycler quand vous le souhaitez ou pas du tout, mais la plupart le laisser à sa valeur par défaut. Merci d'avoir répondu!
Guy

18

OK, cela me dérangeait, alors j'ai fouillé et j'ai finalement trouvé cette publication d'un gars qui apparemment faisait partie de l'équipe IIS:

La raison pour laquelle IIS6 recycle toutes les 29 heures par défaut (et nous avions une raison

La raison pour laquelle IIS6 recycle toutes les 29 heures par défaut (et nous avions une raison de choisir 29 heures comme valeur par défaut) est que, plus probablement qu'autrement, l'application Web qui s'exécute sur elle n'est pas fiable et doit littéralement redémarrer fréquemment.

Ainsi, IIS6 est construit sur la prémisse (certes cynique) que l'application Web de l'utilisateur ne fonctionnera pas pendant plus de 24 heures contiguës, les fonctionnalités sont planifiées en conséquence et les valeurs par défaut choisies. Les processus de travail sont recyclés toutes les 29 heures, le démarrage et l'arrêt du processus sont surveillés, le processus est constamment ping pour s'assurer qu'il est en cours d'exécution, le descripteur du processus est suivi et signalé lorsqu'il se termine de manière inattendue, etc., etc.

Réalisant que le recyclage fait partie intégrante des opérations, IIS6 veille également à isoler ce recyclage de l'utilisateur final - la connexion TCP de l'utilisateur final ne se termine jamais pendant un recyclage, en raison d'une certaine magie en mode noyau. Combiné avec une application en mode utilisateur qui stocke hors processus l'état de session (comme ASP.Net Session State Service), une disponibilité fiable est pratiquement garantie sans perte de données visible par l'utilisateur, même si l'application Web se bloque après le traitement de chaque demande de l'utilisateur.

C'est à peu près aussi bon que IIS6 peut le faire - étant donné une application Web peu fiable, la faire paraître fiable pour l'utilisateur final et le faire sans nécessiter de correctifs de l'application Web non fiable.

Bien sûr, toutes les applications non fiables ne peuvent pas sembler fiables - si c'est le cas, alors nous sommes tous sans emploi! - mais IIS6 essaie certainement beaucoup plus d'être résilient.

Dans votre cas, il se trouve que la résiliation a un effet secondaire sur l'état utilisateur non persistant, mais elle peut être facilement ajustée.

En supposant que votre application Web n'a jamais de problème et reste avec l'état de session en cours, vous souhaiterez modifier ces valeurs par défaut: 1. Désactivez le recyclage périodique de 29 heures 2. Désactivez le délai d'inactivité de 20 minutes

Cela empêchera la perte inattendue de l'état de session.

Bien sûr, si vous utilisez une application avec un état de session hors processus, vous pouvez tout laisser comme paramètres par défaut et ne jamais remarquer de différence de fonctionnalité ou de fiabilité.


1
Je me sens stupide de demander cela, mais si IIS suppose que l'application Web ne parvient pas à 24 heures, pourquoi 29 était-il un bon choix? N'auraient-ils pas dû choisir un nombre inférieur à 24? Où ai-je tort d'interpréter cette explication?
Alpha

Il n'y a peut-être pas de «meilleure» réponse pour la valeur par défaut, et la personne qui gère le site Web devrait prendre une décision délibérée en fonction de l'application et du système.
DOK

@Alpha - Je suis d'accord - cela n'a pas de sens - il devrait passer par défaut à 22 ou 23 heures ou au moins quelque chose de moins de 24.
Guy

[citation nécessaire]
piers7

Je reçois chaque matin une étrange erreur de compilation sur des parties du site Web qui ne peuvent être corrigées qu'avec un recyclage. Je suppose que le délai d'inactivité se déclenche pendant la nuit en raison d'une faible charge, et pour une raison quelconque, lorsqu'il redémarre, l'erreur de compilation est de retour. Merci pour le plomb, je vais suivre ce chemin pour résoudre mon problème ...
sonjz
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.