48、IIS 7.0 性能监控、诊断与故障排除全解析

IIS 7.0 性能监控、诊断与故障排除全解析

1. 性能监控与调优的重要性

在当今的技术环境中，技术团队常常面临着以更少资源完成更多任务的压力。充分发挥 Web 服务器的性能是提升公司竞争力的有效途径，同时也能让团队避免投入大量成本来增加和管理服务器容量。而实现 Web 应用最大效益的关键在于良好的监控程序和智能的性能调优。

2. 监控解决方案与工具

为了收集和呈现 IIS 服务器的性能数据，我们可以使用多种工具。商业软件如 Symantec 的 i3 或 HP Mercury 的 SiteScope 都是不错的选择，同时 Windows Server 2008 也集成了一些出色的工具。以下是一些值得熟悉的工具：
- 任务管理器 ：可快速访问服务和应用程序的实时数据。
- 可靠性和性能监控控制台 ：能生成关于事件跟踪的详细报告。

即使你拥有商业监控工具，也需要不时打开可靠性和性能监控器。性能数据主要用于容量规划、诊断和性能调优等方面。

3. 性能调优的方向

在收集和审查性能数据后，需要对平台进行调优。可以从以下几个方面进行重大调整：
- 操作系统优化
- IIS 服务优化
- 网站优化

在进行配置时，应根据服务器的需求进行设置。虽然相关建议是基于多年经验和微软最佳实践得出的，但在投入生产前，仍需在公司环境中进行测试和验证。

4. 常见问题类型

IIS 7.0 可能遇到的问题主要分为以下几类：
|问题类型|描述|特点|
| ---- | ---- | ---- |
|特定错误|通常快速失败，并显示与错误对应的 HTTP 错误页面。部分错误（如 500 HTTP 状态码）会有自定义错误页面，包含用于故障排除和调试的详细信息。|错误信息能迅速缩小问题范围，易于重现，每次失败情况相同。|
|挂起/超时问题|在过去的 IIS 版本中，这类问题很难排查。错误信息通常只显示超时，不提供原因线索。|难以重现，失败前通常需要较长时间，每次测试可能需等待很久。|
|资源密集和缓慢问题|可能导致服务器 CPU 飙升、磁盘使用过度、内存占用高或几乎任何资源过度使用。|负面影响通常不会立即显现，有时在预生产负载测试中也难以发现。排查时，唯一线索可能只是网站运行比正常情况慢，原因可能涉及服务器、网络、数据库服务器或第三方组件等。|

5. 运行时状态和控制 API（RSCA）

IIS 7.0 通过运行时状态和控制 API（RSCA），让管理员可以查看服务器的实时状态，包括所有正在运行的页面请求、应用程序域和活动站点。这相比 IIS 6.0 是一个重大进步，大大简化了对长时间运行页面请求的故障排除。RSCA 可以通过多种方式使用，如 IIS 管理器和 AppCmd.exe。

5.1 查看工作进程

在 IIS 管理器中，双击“工作进程”图标，可查看服务器级别的运行请求。工作进程视图将显示应用程序池名称、进程 ID、当前状态、CPU、私有字节和虚拟字节等信息。

不同工具对虚拟字节和私有字节的显示方式有所不同：
- 任务管理器 ：“提交大小”列对应 RSCA 中的“私有字节”值，但默认不显示该列，需通过“视图” -> “选择列”添加。任务管理器中没有与“虚拟字节”匹配的列。
- 性能监视器 ：名称与 RSCA 一致，但 RSCA 以千字节为单位报告值，而性能监视器以字节为单位。若要使值完全匹配，需将性能监视器的值除以 1024。

使用 AppCmd.exe 查看所有运行的工作进程，可执行以下命令：

appcmd.exe list wp

由于 AppCmd.exe 所在路径（%windir%\system32\inetsrv）不在系统路径中，可通过以下方式解决：
- 将其添加到系统路径。
- 导航到该路径。
- 输入完整路径，如：%windir%\system32\inetsrv\appcmd.exe list wp。

也可以根据应用程序池名称或工作进程 ID 进行过滤，例如：

appcmd.exe list wp /apppool.name:DefaultAppPool
appcmd.exe list wp /wp.name:2668 （appcmd.exe list wp 2668 是简写方式）

以下是一个使用 WMI 的简单 VBScript 示例，可生成与 appcmd list wp 类似的输出：

Set oService = GetObject("winmgmts:root\WebAdministration")
Set oWorkerProcesses = oService.InstancesOf("WorkerProcess")
For Each WP In oWorkerProcesses
    strPID = "WP """ & WP.ProcessId & """"
    strAppPool = "(applicationPool:" _
        & WP. AppPoolName & ")"
    WScript.echo(strPID & " " & strAppPool)
Next

5.2 查看页面请求

在 IIS 管理器中，双击要深入查看的工作进程，可查看该工作进程的所有页面请求。请求部分将显示网站 ID、URL、动词、客户端 IP 地址、状态、模块名称和已用时间等信息。

请求可以根据运行时间（即“已用时间”）进行过滤。在“请求”部分的“过滤器”字段中输入 0 到 2147482 之间的秒数，然后按“转到”，将显示运行时间等于或长于该时间的所有页面请求。若要清除过滤器，点击“显示全部”按钮。

使用 AppCmd.exe 也可获取相同信息，还能通过传递额外参数过滤请求 ID、站点名称、工作进程 ID、应用程序池名称和已用时间等。例如，查看所有运行的请求：

appcmd.exe list request

查看运行时间超过 5 秒（5000 毫秒）的页面请求：

appcmd.exe list request /elapsed:5000

5.3 查看应用程序域

应用程序域（AppDomains）是 ASP.NET 的关键部分，但过去大多处于隐藏状态。IIS 会为每个设置为应用程序的文件夹创建单独的 AppDomain，开发人员也可通过代码设置自己的 AppDomain 以实现代码隔离。

以下是一个使用 WMI 的简单 VBScript 示例，可查看所有运行的应用程序域：

Set oService = GetObject("winmgmts:root\WebAdministration")
Set oAppDomains = oService.InstancesOf("AppDomain")
For Each AppDomain In oAppDomains
    WScript.echo("ID: " & AppDomain.Id)
    WScript.echo("  ApplicationPath: " & AppDomain.ApplicationPath)
    WScript.echo("  PhysicalPath:    " & AppDomain.PhysicalPath)
    WScript.echo("  Process Id:      " & AppDomain.ProcessId)
    WScript.echo("  SiteName:        " & AppDomain.SiteName)
    WScript.echo("  IsIdle:          " & AppDomain.IsIdle)
    WScript.echo("")
Next

通过 RSCA，系统管理员无需安装第三方产品，也无需重启系统，即可实时查看运行进程、页面请求、应用程序域等大量信息。

6. IIS 7.0 错误页面

IIS 7.0 支持自定义错误页面，可根据不同需求进行设置，以满足隐藏错误细节、显示友好页面或向管理员发送详细信息等目的。自定义错误页面可针对每个 HTTP 状态码和可选的子状态码进行设置。

IIS 7.0 可返回的错误类型主要有两种：
- 自定义错误 ：普通网站用户会看到的错误，包含错误的简要描述，不应包含敏感信息。可根据需求自定义页面内容，通常应隐藏真实错误，向用户显示友好页面。
- 详细错误 ：包含大量信息，供本地管理员和开发人员使用。由于可能包含错误的敏感信息，不应向最终用户显示。

默认情况下，IIS 7.0 会根据请求来源显示不同的错误页面：来自本地服务器的请求显示详细错误，其他请求显示自定义错误。不过，也可以更改默认行为，使所有请求都显示详细错误或自定义错误。

Internet Explorer 默认会显示友好错误消息，可通过“工具” -> “Internet 选项” -> “高级”，取消勾选“显示友好 HTTP 错误消息”来禁用该功能。

对于由 ASP.NET 处理的页面，默认仍使用 ASP.NET 错误处理程序。可通过设置 httpErrors 元素的 existingResponse 属性来更改：
- Auto ：允许应用程序（如 ASP.NET）决定使用自己的错误页面还是 IIS 的错误页面。这是默认设置，意味着 ASP.NET 页面使用 ASP.NET 错误页面，大多数非 ASP.NET 页面使用 IIS 7.0 自定义错误页面。
- Replace ：强制 IIS 始终使用 IIS 7.0 错误页面。优点是错误页面一致，便于统一管理，但 IIS 7.0 在处理 ASP.NET 请求时提供的详细信息不如 ASP.NET。
- PassThrough ：允许应用程序的错误页面直接通过，IIS 7.0 不进行拦截和显示自己的错误页面。选择此设置后，即使是静态页面和其他通用页面也不会显示 IIS 7.0 自定义错误页面。

使用 AppCmd.exe 可更改模式，例如将模式设置为 Replace：

appcmd.exe set config /section:httpErrors /existingResponse:Replace

若要更改回 Auto 或更改为 PassThrough，只需将 Replace 替换为相应的值即可。

7. 自定义错误页面的设置

在 IIS 管理器中，可在服务器、站点或应用程序级别更改 IIS 7.0 错误页面。需要注意的是，此操作只能更改自定义错误页面，无法更改详细错误页面。

在添加或编辑错误页面时，可设置主要状态码，并可选择设置子状态码。创建或编辑错误页面时，IIS 提供了三种显示错误页面的方式：
- 从静态文件插入内容到错误响应 ：显示简单的静态页面，默认方式，速度快，无需经过 ASP.NET 引擎预处理。可选择系统上的任何文件，还可针对不同语言提供不同页面。
- 执行此站点上的 URL ：显示指定的页面，会通过 ASP.NET 引擎处理，以实现动态内容。该页面必须是相对 URL，且与引发错误的页面位于同一应用程序池中。
- 以 302 重定向响应 ：将页面请求重定向到新页面，新页面可位于同一服务器或不同服务器，无需与引发错误的页面位于同一应用程序池。

在 IIS 管理器的同一工具中，还可在三种错误响应类型之间切换：自定义错误页面、详细错误以及本地请求显示详细错误而远程请求显示自定义错误页面。可通过右侧操作窗格中的“编辑功能设置”进入设置窗口。

8. 多语言支持

IIS 7.0 支持多语言，可根据浏览器语言显示不同的错误页面。现代浏览器会在 Web 请求中发送指定客户端语言的 HTTP 头。在设置自定义错误页面时，若选择“从静态文件插入内容到错误响应”，有一个“尝试以客户端语言返回错误”的复选框。勾选后，点击“设置”按钮，可设置根目录路径和相对文件路径。当发生错误时，IIS 会组合根目录 + 语言 + 相对文件路径。在英文版 Windows Server 2008 中，默认的自定义错误文件夹为 %SystemDrive%\inetpub\custerr\en-US\，可从 www.microsoft.com/downloads 获取额外的语言包。

IIS 处理子状态码时，会先检查是否为子状态码设置了特定错误页面，若没有则检查主要状态码，若仍未设置则使用默认错误页面。

9. HTTP 状态码与 FTP 状态码

当用户通过 HTTP 或文件传输协议（FTP）访问运行 IIS 的服务器上的内容时，IIS 会返回一个数字代码，指示请求的状态。该状态码会记录在 IIS 日志中，也可能显示在 Web 浏览器或 FTP 客户端中。状态码可分为以下几类：
|状态码类别|描述|
| ---- | ---- |
|1xx - 信息性|表示临时响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。|
|2xx - 成功|表示服务器成功接受了客户端请求。|
|3xx - 重定向|客户端浏览器需要采取更多操作才能完成请求。例如，浏览器可能需要请求服务器上的不同页面或通过代理服务器重复请求。|
|4xx - 客户端错误|表示发生错误，客户端似乎存在问题。例如，客户端可能请求不存在的页面，或未提供有效的身份验证信息。|
|5xx - 服务器错误|表示服务器因遇到错误而无法完成请求。|

除了 HTTP 状态码，还有一些 FTP 状态码可用于排查 FTP 相关问题。

综上所述，通过合理运用监控工具、了解常见问题类型及处理方法、掌握错误页面设置和状态码含义等，我们可以更好地管理和维护 IIS 7.0 服务器，确保其稳定高效运行。

IIS 7.0 性能监控、诊断与故障排除全解析

10. 不同类型问题的具体排查方法

对于不同类型的问题，我们需要采用不同的排查方法，以下是详细介绍：

10.1 特定错误排查

特定错误通常会快速失败，并显示对应的 HTTP 错误页面。例如，当忘记设置默认文档时，IIS 7.0 会给出详细的错误信息，包括具体情况、可能原因、解决建议以及相关信息链接。排查此类错误时，可按照以下步骤进行：
1. 查看错误页面信息，明确错误类型和可能原因。
2. 根据错误提示，检查相关配置，如文件路径、权限设置等。
3. 尝试重现错误，验证问题是否解决。

10.2 挂起/超时问题排查

在过去的 IIS 版本中，挂起/超时问题很难排查，而 IIS 7.0 借助 Failed Request Tracing 和 RSCA 使排查变得更容易。排查步骤如下：
1. 启用 Failed Request Tracing，设置相关规则，记录可能导致挂起或超时的请求。
2. 使用 RSCA 查看运行中的工作进程和页面请求，确定是否存在长时间运行的请求。
3. 分析记录的数据，找出可能的原因，如资源耗尽、代码死循环等。

10.3 资源密集和缓慢问题排查

这类问题通常导致服务器资源过度使用，排查难度较大。可按以下步骤进行：
1. 使用性能监控工具，如任务管理器、性能监视器，查看服务器资源使用情况，确定是 CPU、磁盘、内存还是其他资源出现问题。
2. 利用 Failed Request Tracing 确定哪些页面运行缓慢，以及页面处理的具体部分。
3. 检查服务器、网络、数据库服务器和第三方组件，找出可能导致问题的根源。

11. 利用 RSCA 进行实时监控的流程

使用 RSCA 进行实时监控可以帮助我们及时发现和解决问题，以下是具体的操作流程：

graph LR
    A[启动 IIS 管理器或使用 AppCmd.exe] --> B{选择操作}
    B -->|查看工作进程| C[双击“工作进程”图标或执行 appcmd.exe list wp]
    C --> D[查看应用程序池名称、进程 ID、状态等信息]
    D --> E{是否需要过滤}
    E -->|是| F[按应用程序池名称或进程 ID 过滤]
    E -->|否| G[查看所有工作进程信息]
    B -->|查看页面请求| H[双击工作进程查看请求或执行 appcmd.exe list request]
    H --> I[查看网站 ID、URL、已用时间等信息]
    I --> J{是否需要过滤}
    J -->|是| K[按已用时间、请求 ID 等过滤]
    J -->|否| L[查看所有页面请求信息]
    B -->|查看应用程序域| M[使用 WMI 脚本查询]
    M --> N[查看应用程序域的 ID、路径等信息]

12. 错误页面设置的最佳实践

为了更好地处理错误情况，以下是一些错误页面设置的最佳实践：
- 自定义错误页面 ：为不同的 HTTP 状态码设置自定义错误页面，向用户显示友好的错误信息，避免暴露敏感信息。
- 详细错误页面 ：在本地开发和测试环境中，启用详细错误页面，以便开发人员和管理员快速定位问题。
- 多语言支持 ：利用 IIS 7.0 的多语言支持功能，为不同语言的用户提供相应的错误页面。
- 定期检查和更新 ：定期检查错误页面的内容和链接，确保其有效性和准确性。

13. 状态码的实际应用

理解 HTTP 和 FTP 状态码对于排查问题非常重要，以下是一些实际应用场景：
|状态码类别|应用场景|处理方法|
| ---- | ---- | ---- |
|1xx - 信息性|在开发和调试过程中，关注此类状态码，确保请求处理正常。|一般无需特殊处理，等待后续正常响应。|
|2xx - 成功|确认请求已成功处理，可用于验证系统的正常运行。|无需处理，继续后续操作。|
|3xx - 重定向|当遇到此类状态码时，检查重定向的原因和目标地址。|根据重定向信息，调整请求或配置。|
|4xx - 客户端错误|分析错误信息，确定是客户端请求问题还是权限问题。|检查请求参数、文件路径和权限设置。|
|5xx - 服务器错误|排查服务器端的问题，如代码错误、资源不足等。|检查服务器日志、代码和配置，解决服务器端问题。|

14. 总结

通过本文的介绍，我们了解了 IIS 7.0 性能监控、诊断与故障排除的相关知识。从性能监控工具的使用，到不同类型问题的排查方法，再到错误页面的设置和状态码的理解，这些技能对于管理和维护 IIS 7.0 服务器至关重要。在实际工作中，我们应根据具体情况灵活运用这些方法，确保服务器的稳定高效运行。同时，不断学习和积累经验，提高自己的故障排除能力。

在日常运维中，建议定期进行性能监控和检查，及时发现潜在问题。遇到问题时，按照本文介绍的步骤进行排查，逐步缩小问题范围，最终解决问题。希望这些知识能帮助你更好地应对 IIS 7.0 服务器的各种挑战。