好的，这里有各种各样的症状（客户和我们自己的员工抱怨间歇性减速，被“踢出”login页面或只是有一个保存请求不正确地保存提交的数据）。
环境：
有大约10个网站在服务器上运行，每个网站都在自己的应用程序池中 – 这些池中的大部分都以集成模式运行，2个是经典的，都在.NET 2.0上，都以ApplicationPoolIdentity的forms运行。
我正在尝试分析，诊断和排除故障，并且正在努力从哪里获得关于可能发生的更多信息。
以下是我已经采取的一些步骤：
我已经看到了应用程序池进程的回收（在任务pipe理器） – 一个新的将启动，然后第一个死亡 – 这发生没有内存或时间超过设置。
这是一个相当新的服务器，其中大部分来自Windows Server 2003 / IIS6。
任何设置信息收集，logging，诊断等“下一步”将非常感激！
Ĵ
应用程序池高级设置允许您为应用程序池打开额外的日志logging。 您可以打开所有的应用程序池回收日志logging。 在健康的情况下不应该喋喋不休，你不介意在排除故障的时候是否有点喋喋不休。
然后在事件查看器中，每当您的应用程序池回收时，都应该logging一个事件。
只是关于内存回收的一个注意事项 – 如果您在任务pipe理器中查看它，您可能不会注意到它已经达到了虚拟字节限制，但是如果设置了事件日志设置，它仍然会触发一个事件。
顺便说一句，任何对App Pool设置的更改都会触发回收。 所以不要去重新确认设置，除非你想要这样做！
为了避免这种情况，请更改属性DisallowRotationOnConfigChange，这将导致应用程序池在计划或强制执行之前不会回收，此时修改了应用程序池设置。
当采取纠正措施时，WAS应该在系统日志中logging事件; 应用程序池故障通常会logging到系统或应用程序（Windows错误报告或应用程序问题）。