上周末，我们运行 IIS 6.0 的网站停止处理对 Web 服务的调用。日志文件中充满了以下错误，直到大约 8 小时后服务器重新启动：
2011-05-08 01:53:12,109 错误 - 无法获取执行权限。
2011-05-08 01:53:12,135 错误 - 在 System.Security.SecurityManager.ResolvePolicy（证据证据、PermissionSet reqdPset、PermissionSet optPset、PermissionSet deniedPset、PermissionSet& denied、布尔 checkExecutionPermission）。
上述错误在网络日志文件中又出现了 316,871 次。
时间很有趣，因为上面的第一个错误是在计划了 29 小时的应用程序池回收之后立即发生的，正如我看到的这个条目：
为应用程序池“gpsigolf.com”提供服务的进程 ID 为“758628”的工作进程已请求回收，因为该工作进程已达到其允许的处理时间限制。
在问题发生前，事件日志（使用事件查看器）中出现了此条目，相关日志文件中也包含执行权限错误。此条目也恰好位于事件日志中上一个此类条目的 29 小时之后。
此后，服务器在多次应用程序池回收后一直运行良好，没有出现任何问题，在出现此问题之前，该服务器已运行了五天。这是我们迁移到的新服务器，因此在出现此问题之前，它总共只运行了五天。
问题是应用程序池回收为何/如何会导致此问题？我们是否应该避免某些设置，例如重叠回收？
答案1
我会在 29 小时（1740 分钟）后关闭回收功能。这只是默认设置，但在生产中没有用。如果必须自动回收，请在非工作时间的设定时间进行。
重叠的应用程序池非常健康。查看这个最近的视频在我的 Web Pro 系列中介绍了这一点。
我猜想发生的情况是，某个程序控制着您网站中的一个关键文件，而 IIS 无法获得该文件的执行权限。直到 IIS 在回收期间释放该文件，其他程序接管后，问题才得以解决。
当这种情况再次发生时（很可能会发生，因为什么都没有改变），我建议使用 Process Monitor 和/或 Process Explorer 来找出哪个文件被锁定。在 Process Monitor 捕获中搜索“denied”应该会找到它。下面是另一个快速有关如何使用进程监视器的视频。