レポート サーバー アプリケーションのアプリケーション ドメイン
Reporting Services では、レポート サーバー Web サービス、レポート マネージャー、およびバックグラウンド処理アプリケーションを含む単一のサービスとしてレポート サーバーが実装されます。 それぞれのアプリケーションは、単一のレポート サーバー プロセス内の独自のアプリケーション ドメインで実行されます。 通常、アプリケーション ドメインは内部的に作成、構成、および管理されます。 ただし、レポート サーバーのアプリケーション ドメインがどのようにリサイクルされるのかを理解しておくと、パフォーマンスまたはメモリの問題を調査したり、中断したサービスをトラブルシューティングしたりする際に、その知識を役立てることができます。
Note
基本認証を使用するレポート サーバーでレポート ビルダーへのアクセスを構成すると、レポート ビルダーは独自のアプリケーション ドメインで実行されます。 このアプリケーション ドメインは、サーバー プロセスで実行される他のアプリケーション ドメインとは異なります。 このドメインは、サービス コントローラーで管理され、レポート サーバーのメモリ負荷に応じてメモリの割り当てを再調整するメモリ管理機能の対象ではありません。
Reporting Services アプリケーションでは、次のようなイベントによってアプリケーション ドメインがリサイクルされます。
定期的なリサイクル処理 (決められた間隔で実行)
レポート サーバーの構成変更
ASP.NET の構成変更。
メモリ割り当ての失敗
次の表では、これらのイベントが発生した場合、アプリケーション ドメインがどのようにリサイクルされるかを簡単に説明します。
Event | イベントの説明 | 適用対象 | 構成可能 | リサイクル処理の説明 |
---|---|---|---|---|
定期的なリサイクル処理 (決められた間隔で実行) | 既定では、アプリケーション ドメインは 12 時間おきにリサイクルされます。 プロセス全体の正常動作を促進する ASP.NET アプリケーションでは、定期的なリサイクル処理は一般的なことです。 |
レポート サーバー Web サービス レポート マネージャー バックグラウンド処理アプリケーション |
はい。 サイクル間隔は、RSReportServer.config ファイルのRecycleTime 構成設定によって異なります。 バックグラウンド処理の完了を待機する最大時間は、MaxAppDomainUnloadTime で設定します。 |
Web サービスとレポート マネージャーのリサイクル処理は、ASP.NET によって管理されます。 バックグラウンド処理アプリケーションの場合、スケジュールに従って開始された新しいジョブの新しいアプリケーション ドメインがレポート サーバーによって作成されます。 既に進行中のジョブは、最大待ち時間に達しない限り、現在のアプリケーション ドメインで完了することが許可されます。 |
レポート サーバーの構成変更 | RSReportServer.config ファイルの変更に応じて、アプリケーション ドメインが Reporting Services によってリサイクルされます。 | レポート サーバー Web サービス レポート マネージャー バックグラウンド処理アプリケーション |
いいえ。 | リサイクル処理を抑制することはできません。 ただし、構成の変更に呼応して発生するリサイクル処理については、定期的なリサイクル処理と同じように処理されます。 新しい要求については、新しいアプリケーション ドメインが作成され、現在の要求およびジョブについては、現在のアプリケーション ドメインで実行されます。 |
ASP.NET の構成変更 | ASP.NET によって監視されているファイル (machine.config および Web.config ファイル、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 | 3 つの Reporting Services アプリケーション ドメインすべて | アプリケーション ドメインがリサイクルされる頻度を指定します。 既定のリサイクル スケジュールは、ASP.NET アプリケーションの標準的なドメイン リサイクル パターン (12 時間) に従います。 スケジュールされた時間になると、新規要求はすべてアプリケーション ドメインの新しいインスタンスに転送されます。 元のインスタンスで処理中の要求はそのまま継続して処理されます。 処理がすべて完了すると、元のインスタンスが削除され、新しいインスタンスだけがアクティブなアプリケーション ドメイン インスタンスとなります。 既定値は 720 分です。 |
MaxAppDomainUnloadTime | バックグラウンド処理アプリケーション ドメインのみ | 既定では、リサイクル中にアプリケーション ドメインがシャット ダウンに費やすことのできる時間として、30 分間の待機時間がレポート サーバーによって割り当てられます。 |
現在処理中のジョブを割り当てられた時間内に完了できない場合、アプリケーションのドメイン インスタンスは直ちに再起動します。 同様に、ジョブが指定された待機時間を超えた場合、アプリケーションのドメイン インスタンスもすぐに再起動します。 未完了のジョブはすべて終了されます。 レポート サーバーで実行されているジョブのステータスを表示したり取り消したりする方法の詳細については、「レポート サーバー ジョブのキャンセル (Management Studio)」を参照してください。 |
Note
IIS でホストされた ASP.NET アプリケーションの machine.config には、リサイクルのスケジュールが指定されている場合もあります。レポート サーバー Web サービスもレポート マネージャーも ASP.NET アプリケーションですが、この構成ファイルで指定されているアプリケーション ドメインのリサイクル スケジュールは、どちらのアプリケーションにも適用されません。