Que dois-je faire pour m'assurer que IIS ne recycle pas mon application?
J'ai une application de service WCF hébergée dans IIS. Au démarrage, il va chercher une ressource très coûteuse (en termes de temps et de CPU) à utiliser comme cache local.
Malheureusement, IIS semble recycler le processus assez régulièrement. J'essaie donc de modifier les paramètres du pool d'applications pour m'assurer que IIS ne pas recycler l'application. Jusqu'à présent, j'ai modifié ce qui suit:
- Limitez l'intervalle sous CPU de 5 à 0.
- Délai d'inactivité sous Modèle de processus de 20 à 0.
- Intervalle de temps régulier sous recyclage de 1740 à 0.
Est-ce que cela suffira? Et j'ai des questions spécifiques sur les éléments que j'ai modifiés:
- Que signifie spécifiquement le paramètre Limit Interval sous CPU? Cela signifie-t-il que si une certaine utilisation du processeur est dépassée, le pool d'applications sera recyclé?
- Que signifie exactement "recyclé"? L'application est-elle complètement démolie et redémarrée?
- Quelle est la différence entre "arrêt du processus de travail" et "recyclage du pool d'applications"? La documentation pour le délai d'inactivité sous Modèle de processus parle de l'arrêt du processus de travail. Alors que les documents pour l'intervalle de temps régulier sous Recyclage parlent du recyclage du pool d'applications. Je ne comprends pas vraiment la différence entre les deux. Je pensais que le w3wp.exe est le processus de travail qui exécute le pool d'applications. Quelqu'un peut-il expliquer la différence d'application entre les deux?
La raison d'avoir les balises IIS7 et IIS7.5 est parce que l'application s'exécutera dans les deux et espère que les réponses sont les mêmes entre les versions.
Image pour référence: 
Recyclage
Le recyclage est généralement * où IIS démarre un nouveau processus en tant que conteneur pour votre application, puis remet l'ancien à ShutdownTimeLimit pour qu'il disparaisse de son propre gré avant d'être tué.
* - généralement: voir le paramètre DisallowOverlappingRotation/"Désactiver le recyclage avec chevauchement"
Il est destructif, en ce que le processus d'origine et toutes ses informations d'état sont rejetés. L'utilisation d'un état de session hors processus (par exemple, State Server ou une base de données, ou même un cookie si votre état est minuscule) peut vous permettre de contourner ce problème.
Mais c'est par défaut chevauché - ce qui signifie que la durée d'une panne est minimisée car le nouveau processus démarre et est connecté à la file d'attente des demandes, avant que l'ancien ne soit informé "vous avez [ShutdownTimeLimit] secondes pour s'en aller. Veuillez vous conformer. "
Paramètres
À votre question: tous les paramètres de cette page contrôlent le recyclage d'une manière ou d'une autre. "Arrêt" pourrait être décrit comme un "recyclage proactif" - où le processus lui-même décide qu'il est temps d'aller et se termine de manière ordonnée.
Le recyclage réactif est l'endroit où WAS détecte un problème et déclenche le processus (après avoir établi un W3WP de remplacement approprié).
Maintenant, voici quelques trucs qui peuvent provoquer le recyclage d'une forme ou d'une autre:
- un ISAPI décidant qu'il est malsain
- tout module qui plante
- délai d'inactivité
- limitation du processeur
- ajustement des propriétés du pool d'applications
- comme votre maman mai a crié à un moment donné: "Arrêtez cueillette, sinon ça ne s'améliorera jamais!"
- échec "ping" * pas vraiment ping en soi, car il utilise un tube nommé - plus de "détection de vie"
- tous les paramètres de la capture d'écran ci-dessus
Que faire:
Généralement:
Désactiver Délais d'inactivité. 20 minutes d'inactivité = boom! Nouveau processus sur la prochaine demande entrante. Mettez cela à zéro.
Désactiver Intervalle de temps régulier - le défaut de 29 heures a été décrit comme "fou", "ennuyeux" et "intelligent "par diverses parties. En fait, seulement deux d'entre elles sont vraies.
Facultativement Activez DisallowRotationOnConfigChange (ci-dessus, Désactivez le recyclage pour les changements de configuration) si vous ne pouvez tout simplement pas arrêter de jouer avec - cela vous permet de modifier n'importe quel paramètre de pool d'applications sans qu'il signale instantanément aux processus de travail qu'il doit être tué. Vous devez recycler manuellement le pool d'applications pour que les paramètres prennent effet, ce qui vous permet de prédéfinir les paramètres, puis d'utiliser une fenêtre de modification pour les appliquer via votre processus de recyclage.
En règle générale, laissez pinging activé . Voilà votre filet de sécurité. J'ai vu des gens l'éteindre, puis le site se bloque indéfiniment parfois, ce qui conduit à la panique ... donc si les paramètres sont trop agressifs pour votre application apparemment très très très lente à répondre, reculez-les un peu et voyez ce que vous obtenez, plutôt que de l'éteindre. (Sauf si vous avez configuré le dumping en mode crash automatique pour les W3WP bloqués via votre propre processus de surveillance)
Cela suffit à faire en sorte qu'un processus bien conduit dure éternellement. S'il meurt, bien sûr, il sera remplacé. S'il se bloque, le ping devrait reprendre cela et un nouveau devrait commencer dans les 2 minutes (par défaut; le pire des calculs devrait être: jusqu'à fréquence de ping + timeout de ping + délai de démarrage avant que les requêtes ne recommencent à fonctionner).
La limitation du processeur n'est pas normalement intéressante, car par défaut, elle est désactivée, et elle est également configurée pour ne rien faire de toute façon; s'il était configuré pour tuer le processus, ce serait un déclencheur de recyclage. Laissez-le. Remarque pour IIS 8.x, la limitation du processeur devient également une option.
Un AppPool (IIS) n'est pas un AppDomain (.Net) (mais peut en contenir un/certains)
Mais ... alors nous entrons dans les terres .Net et le recyclage AppDomain, ce qui peut également entraîner une perte d'état. (Voir: https://blogs.msdn.Microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/ )
Version courte, vous faites cela en touchant un fichier web.config dans votre dossier de contenu (encore une fois avec la cueillette!), Ou en créant un dossier dans ce dossier, ou un fichier ASPX, ou .. autres choses ... et c'est = à propos aussi destructif qu'un recyclage de pool d'applications, moins les coûts de démarrage du code natif (c'est purement un concept de code managé (.Net), donc seulement du code managé) arrive ici).
L'antivirus peut également déclencher cela car il analyse les fichiers web.config, provoquant une notification de modification, provoquant ....
Bien vouloir vérifier,
Pourquoi recyclons-nous nos pools d'applications?
si vous naviguez sur le Web pour trouver la raison pour laquelle les pools d'applications sont configurés pour recycler automatiquement périodiquement, , vous aurez du mal à trouver une réponse raisonnable qui ne concerne pas les problèmes de mémoire. C'est comme si la communauté en général acceptait à peu près le fait que nos applications Web (ou les couches de service hébergées dans IIS) devront être recyclées pour éviter les problèmes de mémoire.
J'ai toujours été d'avis que si votre code nécessite des redémarrages périodiques pour continuer à fonctionner correctement, alors quelque chose ne va clairement pas. Il y a un bug dans votre code quelque part et vous devez le corriger, au lieu de redémarrer le processus de temps en temps pour faire disparaître le problème.
Il faut vraiment commencer à se concentrer davantage sur gestion de la mémoire dans .NET et à s'assurer que nos applications peuvent continuer à fonctionner sans problème.
Basé sur le scénario OP (initialisation longue au démarrage/préchauffage), une autre chose à vérifier est Limite de temps de démarrage (secondes) qui a une valeur par défaut de 90 secondes. Si l'initialisation prend plus que la limite de temps de démarrage, le processus de travail peut être interrompu.