我有2个带有镜像内容的Web服务器。 有一个负载平衡器坐在他们面前。
从昨天开始，我们一直在让人们抱怨503错误。 我无法findIIS日志文件中的任何503错误。 然而，服务器主机说这些错误是由于我们网站的.Net错误导致应用程序池回收。
他们指出了Windows应用程序事件日志中的几个错误，如下所示：
Log Name: Application Source: ASP.NET 4.0.30319.0 Date: 3/31/2012 8:35:37 PM Event ID: 1309 Task Category: Web Event Level: Warning Keywords: Classic User: N/A Computer: 6251.local Description: Event code: 3005 Event message: An unhandled exception has occurred. Event time: 3/31/2012 8:35:37 PM Event time (UTC): 4/1/2012 1:35:37 AM Event ID: e7a580c7b38545cca3416a8595408f24 Event sequence: 97 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/2/ROOT-1-129777167518960645 Trust level: Full Application Virtual Path: / Application Path: C:\inetpub\wwwroot\mywebsite\ Machine name: 6252 Process information: Process ID: 20000 Process name: w3wp.exe Account name: IIS APPPOOL\MyAppPool 特别是他们说“进程信息”下的帐户名称表示应用程序池正在回收。 他们表示，如果应用程序池没有被回收，那么这个帐户名就会成为网站文件所在的文件夹。
我检查了应用程序池设置 – 它设置为每29小时回收。 快速失败保护在5分钟内被设置为5次失败的默认值。 但是在短时间内我还没有看到事件日志中的5次失败。
任何人都可以帮助我确认503响应确实是由应用程序池回收生成？ 还是这些错误来自别的地方？ 我当时的猜测是他们的负载平衡器是实际返回503错误的那个。 但这只是一个猜测。
你已经提到了“IIS日志文件”（单数），但总是有 两个日志需要评估：
503s更有可能出现在HTTPERR日志中，同时还有失败的原因，因为它们更可能反映HTTP.SYS与工作进程通信失败（或者队列溢出，这相当于类似的事情）。
另请参阅http://support.microsoft.com/kb/820729 – 不确定为什么当文章描述日志logging的function时，为什么会有“修复”，以及（在底部）可能会logging失败的原因。
多一点
大多数应用程序框架中有两个队列 – HTTP.SYS请求队列（在内核模式下）和用户模式请求队列。 如果用户模式框架（如ASP.Net）在内部排队请求，那么工作进程的失败将导致在其中排队的所有请求的503（或至多500），导致HTTP.SYS将这些请求作为废弃和无法挽回的。
如果您的应用程序因未处理的exception而失败，则需要修复 – IIS体系结构没有任何措施可以将{应用程序批处理}从{应用程序本身}隔离开来，并且您将获得某种forms的错误客户端 – 回收确保有一个新的工作进程准备好第二次尝试。
感谢tristank为您的答案。 我不知道httperr日志。
在这个特定情况下，事实certificate，客户端订购了第三台服务器与负载均衡器轮stream添加，但客户端从未告诉我。 所以第三台服务器基本上是空白的。 所以任何时候负载均衡器发送一个请求，我相信发生了一些奇怪的事情。