我有 2 台带有镜像内容的 Web 服务器。它们前面有一个负载均衡器。
从昨天开始，我们就不断有人抱怨 503 错误。我在 IIS 日志文件中找不到任何 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 错误。但那只是猜测。
答案1
您提到了“IIS 日志文件”（单数），但还有总是 二您需要评估的日志：
- W3SVCnn来自网站工作进程的日志（C:\Inetpub\Logs），以及
- HTTP错误来自 HTTP.SYS 的日志（C:\Windows\System32\Logfiles\HTTPERR），它将请求路由到工作进程，并提供一个内核模式队列，旨在缓冲客户端的工作进程变化（如回收）
503 更有可能出现在 HTTPERR 日志中，同时出现失败原因，因为它们更有可能反映 HTTP.SYS 与工作进程通信失败（或队列溢出，这与此类似）。
也可以看看http://support.microsoft.com/kb/820729- 不确定为什么在文章描述日志记录的作用以及（在底部）可能记录失败的原因时会出现“修复它”。
多一点
大多数应用框架中有两个队列 - HTTP.SYS 请求队列（内核模式）和用户模式请求队列。如果用户模式框架（如 ASP.Net）在内部对请求进行排队，则工作进程的故障将导致其中排队的所有请求都出现 503（或最多 500）错误，从而导致 HTTP.SYS 将这些请求视为已放弃且无法挽救。
如果您的应用程序因未处理的异常而失败，您需要修复该问题 - IIS 架构无法将 {正在进行的请求批次} 与 {应用程序启动本身} 隔离开来，并且您会收到某种形式的错误传达给客户端 - 回收可确保有一个新的工作进程准备好为第二次尝试提供服务。
答案2
感谢 tristanK 的回答。我不知道 httperr 日志。
在这个特定案例中，客户下令将第三台服务器添加到负载均衡器的轮换中，但客户从未告诉我。因此，第三台服务器基本上是空白的。因此，每当负载均衡器向它发送请求时，我确信会发生一些奇怪的事情。