报表服务器应用程序的应用程序域

在 Reporting Services 中，报表服务器作为一个包含报表服务器 Web 服务、报表管理器和后台处理应用程序的服务来实现。 每个应用程序都在单个报表服务器进程中其各自的应用程序域中运行。 通常，在内部创建、配置和管理应用程序域。 但是，如果要研究性能或内存问题或排除服务中断故障，则了解如何针对报表服务器应用程序域执行回收操作会非常有帮助。

注意

如果对使用基本身份验证的报表服务器配置报表生成器访问，则报表生成器将在其自己的应用程序域中运行。 此应用程序域与服务器进程中运行的其他应用程序域不同。 它由服务控制器进行管理，并且不受内存管理功能的限制，这些功能会为响应报表服务器上内存不足而重新调整内存分配。

下面列出了可能会导致针对 Reporting Services 应用程序执行应用程序域回收操作的事件：

• 以预定义的时间间隔执行的计划回收操作。

• 报表服务器上的配置更改。

• ASP.NET 配置更改。

• 内存分配失败。

下表总结了为响应这些事件而发生的应用程序域回收行为：

事件	事件说明	适用于	可配置性	回收操作说明
以预定义的时间间隔执行的计划回收操作	默认情况下，应用程序域每 12 个小时回收一次。 对于提升了总体进程运行状况的 ASP.NET 应用程序来说，计划的回收操作是通常的做法。	报表服务器 Web 服务 报表管理器 后台处理应用程序	是的。 RSReportServer.config 文件中的RecycleTime 配置设置可以确定回收时间间隔。 MaxAppDomainUnloadTime 设置了能够在其间完成后台处理的等待时间。	ASP.NET 管理 Web 服务和报表管理器的回收操作。 对于后台处理应用程序，报表服务器为那些从计划中启动的新作业创建一个新的应用程序域。 已在进行中的作业将能够在当前的应用程序域中完成，直到等待时间过期。
报表服务器上的配置更改	Reporting Services 会为了响应 RSReportServer.config 文件中的更改而回收应用程序域。	报表服务器 Web 服务 报表管理器 后台处理应用程序	错误。	无法禁止执行回收操作。 但是，为了响应配置更改而执行的回收操作将按照与计划的回收操作相同的方式进行处理。 将为新请求创建新的应用程序域，而当前的请求和作业将在当前的应用程序域中完成。
ASP.NET 配置更改	如果所监视的文件（例如，machine.config 文件、Web.config 文件和 ASP.NET 程序文件）发生了更改，则 ASP.NET 会回收应用程序域。	报表服务器 Web 服务 报表管理器	不是。	ASP.NET 对该操作进行管理。 由 ASP.NET 启动的回收操作不会影响后台处理应用程序域。
内存不足和内存分配失败	如果内存分配失败或服务器的内存严重不足时，SQL Server CLR 会立即回收应用程序域。	报表服务器 Web 服务 报表管理器 后台处理应用程序	错误。	在内存严重不足时，报表服务器不接受当前应用程序域中的新请求。 在此期间，服务器将拒绝新请求，并且会出现 HTTP 503 错误。 除非卸载旧应用程序域，否则不会创建新应用程序域。 如果在服务器内存严重不足时对配置文件进行更改，则正在进行的请求和作业可能无法启动。 此外，也可能无法按预期完成。 如果内存分配失败，则会立即重新启动所有应用程序域。 正在进行的作业和请求将被放弃。 您必须手动重新启动这些作业和请求。

计划内和计划外回收操作

根据导致回收操作的条件，回收操作可以是计划内操作或计划外操作：

• 计划内回收操作按在 RSReportServer.config 文件中定义的固定时间间隔发生。 默认值为每 12 个小时。 对于提升了总体进程运行状况的 ASP.NET 应用程序来说，此设置是通常的做法。 对于计划内回收操作，报表服务器会为新请求创建其他应用程序域。 已在进行中的请求将能够在当前的应用程序域中完成，直到等待时间过期。 对于服务器来说，用来控制计划内回收操作的配置设置将作为一个整体来设置。 无法为每个应用程序配置不同的回收计划或内存阈值。

• 为了响应配置更改、内存不足和内存分配失败，随时都可能发生计划外回收操作：

  • 对于配置更改，报表服务器会尝试使用软回收操作，将新请求重定向到应用程序域的新实例。 如果软回收失败，报表服务器将启动对应用程序域的硬回收，即，取消所有正在进行的请求、关闭当前的应用程序域并重新启动应用程序域。

  • 内存分配失败是指系统资源对于服务器所执行的报表处理量来说不足。 所有应用程序域的硬回收操作都是为了响应内存分配失败而执行的。 所有的请求队列都将被清除。 已取消的请求将不会重新动。 正在以交互方式查看报表的用户必须刷新或重新打开报表。 计划的处理会在下一个预定时间发生。 如果无法接受这种延迟，则可以手动刷新报表快照，或者修改订阅计划或报表快照计划，以便它立即运行。

报表服务器 Web 服务、报表管理器和后台处理应用程序的应用程序域可以在一起回收，也可以单独回收，具体取决于导致进行回收的情况：

• ASP.NET 启动的回收操作只会影响 Reporting Services ASP.NET 应用程序：报表服务器 Web 服务和报表管理器。 ASP.NET 会根据其所监视的文件是否发生了更改来回收应用程序域。 由 ASP.NET 启动的回收操作通常独立于后台处理应用程序的回收操作。

• 由报表服务器执行的回收操作通常会影响报表服务器 Web 服务、报表管理器和后台处理应用程序。 回收操作是为了响应配置设置更改和服务重新启动而执行的。

应用程序域的 RSReportServer 配置设置

配置设置是在 RSReportServer.config 文件中指定的。 下面的示例演示了计划内应用程序域回收行为的默认配置设置。

<RecycleTime>720</RecycleTime>

<MaxAppDomainUnloadTime>30</MaxAppDomainUnloadTime>

下表对这些元素进行了说明。

元素	适用于	定义
RecycleTime	所有三个 Reporting Services 应用程序域	指定应用程序域的回收频率。 默认回收计划遵循通常用于 ASP.NET 应用程序域回收的 12 小时制模式。 在计划的时间，所有的新请求都将转发到新的应用程序域实例。 原始实例中当前正在处理的请求能够完成。 一旦完成所有进程，就会删除原始实例，新的实例将成为唯一的活动应用程序域实例。 默认值为 720 分钟。
MaxAppDomainUnloadTime	仅限后台处理应用程序域	默认情况下，报表服务器分配的等待时间为 30 分钟，这是在回收操作期间允许应用程序域关闭的时间。
如当前正在处理的作业无法在分配的时间内完成，则会立即重启应用程序域实例。 同样，如作业超过指定的等待时间，应用程序域实例也会立即重启。 所有未完成的作业都将终止。 有关如何查看状态或取消报表服务器上所运行作业的详细信息，请参阅取消报表服务器作业 (Management Studio)。

注意

尽管报表服务器 Web 服务和报表管理器是 ASP.NET 应用程序，但是，这两个应用程序都不响应可能已在 machine.config 中为 IIS 中所承载的 ASP.NET 应用程序指定的计划应用程序域回收。

相关内容

RsReportServer.config 配置文件
修改 Reporting Services 配置文件 (RSreportserver.config)
为报表服务器应用程序配置可用内存