J'ai cherché des informations à ce sujet en vain. Le contexte de la raison pour laquelle j'ai besoin de ceci est une autre question que j'ai posée ici . Plus spécifiquement, la création/mise à jour/suppression de fichiers dans App_Data entraîne-t-elle un recyclage du pool?
Si quelqu'un pouvait fournir une liste détaillée de ce qui provoque un recyclage, ce serait formidable.
UPDATE: Comme deux utilisateurs l'ont déjà remarqué, je serais également heureux de recevoir une réponse précisant les raisons du recyclage de l'AppDomain uniquement, et non de l'ensemble du pool.
Deux effets différents: le processus AppPool est l'hôte de plusieurs domaines d'application potentiellement multiples. En règle générale, cela peut être recyclé par un certain nombre d’effets, par ex. heure - toutes les minutes, manque de demandes, utilisation de la mémoire, etc. Configuré dans le Gestionnaire de configuration IIS.
AppDomain - L'instance hébergée de la racine de votre application peut être cyclée plus fréquemment sans affecter les autres AppDomains de l'AppPool. Le message de Tess sur le recyclage AppDomain est assez perspicace
Vous écrivez dans un dossier surveillé pour la recompilation - ceci déclenchera la recréation appdomain à un moment donné.
Le journal des événements vous aidera à déterminer la cause du recyclage.
L'article que vous avez aimé dans l'autre article a vraiment fait du très bon travail à cet égard.
Recyclage immédiat
Retarder le recyclage
Peut se produire avec plusieurs modifications à d’autres emplacements. En général, j’ai seulement remarqué cela avec les modifications apportées aux fichiers .aspx ou .cs/.vb. Ajouter du texte temporaire, des fichiers csv ou d'autres fichiers n'a pas entraîné de problèmes pour moi.
REMARQUE: Il s'agit de tous les recyclages de domaine d'application et non de recyclages réels du pool. En règle générale, l'application POOL ne recycle qu'en fonction des paramètres définis dans IIS (nombre de demandes, limite de mémoire, durée d'inactivité ou redémarrage planifié).
Vous voudrez peut-être activer tous les journaux d'événements d'AppPool Recycle:
cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255
Vous pouvez également consulter cet article du blog Scott Guthrie: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx qui montre comment écrire du code dans Global .ASAX pour enregistrer la cause réelle d’un événement Application.End.
Cela nous a été extrêmement utile pour diagnostiquer plusieurs problèmes épineux - l'un d'entre eux était une application qui écrivait des fichiers journaux dans le répertoire wwwroot - trop de modifications de fichiers entraînant un recyclage ...
Cela peut se produire quotidiennement en fonction des préférences ou lorsque la mémoire virtuelle maximale du processus a été dépassée.
Il s'agit d'un paramètre que vous pouvez manipuler pour recycler le pool d'applications en fonction du nombre de minutes d'exécution ou du nombre de demandes traitées.
Il permettra également de recycler les modifications de web.config et d'autres éléments publiés ici.
Une réinitialisation IIS fera également l'affaire, de même que l'arrêt/le démarrage des services.
w3wp.exe
était en erreur. Cela provoquait l'appel de Application_Start
dans Global.asax
.
Pour le savoir, j'ai ouvert Observateur d'événements .
Sous Journaux Windows je suis allé sur Application .
J'ai vu une Erreur d'application :
Faulting application name: w3wp.exe, version: 10.0.16299.15, time stamp: 0x0aeb5595
Faulting module name: KERNELBASE.dll, version: 10.0.16299.334, time stamp: 0x6369e29f
Exception code: 0xe0434352
Fault offset: 0x0000000000014008
Faulting process id: 0x2900
Faulting application start time: 0x01d43b16f726cbb9
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 998cf55d-2cd9-4b8d-9884-2110e3fd1411
Faulting package full name:
Faulting package-relative application ID: