如何确定我的ASP.NET应用程序被回收的原因

我正在IIS7服务器上运行ASP.NET应用程序。它已经运行了很长一段时间，但在过去的一周左右，它已经放弃了所有用户的会话一天好几次。我启用了中所述的所有应用程序池回收日志记录选项，但在事件日志中没有任何内容

事件日志中没有错误，也没有可见的症状，只是我的所有用户都失去了会话

---

IIS会回收我的应用程序池还有其他原因吗？是否有其他类型的日志记录可以让我了解发生了什么情况？

当您遇到这种情况时，您最近如何将文件部署到服务器上

编译标记上有一个名为numRecompilesBeforeAppRestart的讨厌的配置选项：

<system.web>
    <compilation debug="true" numRecompilesBeforeAppRestart="15">

该值默认为15。我曾经经历过一个应用程序杀死所有用户会话，这是我的罪魁祸首。在一个很少使用的web应用程序被更新（新文件被复制到服务器上；这最终覆盖了每个文件，数量多达数百个）后的大约一天内，我们会不断地重新启动AppDomain，所有用户的所有会话值都消失了

我发现此错误报告列出了我正在经历的行为：

以下是与我的场景相关的非常重要的文本：

但是，当您 将许多新的.aspx或.ascx文件加载到 服务器（例如，61个文件）。 服务器卸载应用程序 重新编译前15个文件时 每次又有15个文件 重新编译，直到服务器到达 61这将导致四次应用程序重新启动，即使只有一次被重新启动 必需的

---

我将值切换到99999，问题就消失了。这意味着我的工作进程将积累更多内存，因此我在IIS AppPool循环设置中添加了每日循环（我的站点没有用户时为凌晨3点）。

您可以在元数据库中设置选项，将不同类型的循环事件记录到事件日志中

有关IIS 6.0，请参阅

例如，要允许记录由于超过专用内存限制而导致的回收事件，请在web服务器上执行以下操作：

cd %systemroot%\inetpub\adminscripts
cscript.exe adsutil.vbs set w3svc/AppPools/YOUR_APP_POOL_NAME/AppPoolRecyclePrivateMemory true

---

这里有一个指向IIS 7.0的[不同]说明的链接：

希望现在它已经打开，通过Google可以更容易地找到。这是一篇有趣的文章，但我的问题不同。这个bug似乎涉及在大型更新后的短时间内多次重新启动应用程序。我们上一次更新是大约一周前，重启时间似乎更长。“短”是相对的。。。当它发生在我身上时，它很容易持续一整天，有时似乎会持续更长时间。我们会更新几百页，这些页面在很长一段时间内都不会被使用。当用户浏览应用程序的较大部分时，应用程序将重新启动。我们早上买一个，几个小时后再买一个，晚上再买一个。根据更新的大小以及页面和控件的大小，问题可能会持续一段时间。因此，在您的情况下，每当用户点击自更新以来未被点击的页面时，就会触发重新启动？首先，我的答案是两年前写的，行为可能会改变。其次，我很确定ASP.NET不会重新编译，除非您更改页面的内容。第三，我认为你需要多个页面，而不是一个页面不断变化（请参阅我引用的文本）。第四，查看上面我的链接（指向MSDN错误的链接），如果您有特定问题，请在SO上写一个实际问题或与Microsoft联系。我找到了一些详细信息。我每小时编写一个脚本来记录IIS工作进程ID。会话问题今天早上再次出现，但当我检查日志时，它显示进程ID仍然相同。因此，由于工作进程重新启动，看起来不会发生这种情况。我在服务器上加载了process Monitor，并使用中的说明在每次应用程序结束时写入事件日志条目。今天又发生了这种情况，记录的消息是“C:\inetpub\wwwroot\'的目录重命名更改通知。JobTraQ目录更改或目录重命名。”进程监视器显示了许多“NotifyChangeDirectory”事件，但我不知道它们来自何处。