BizTalk 層のボトルネックの特定
BizTalk 層は以下の機能領域に分割できます。
受信
処理中
送信
追跡
その他
これらの領域でシステム リソース (CPU、メモリ、およびディスク) が飽和状態になっている場合は、スケール アップによってサーバーをアップグレードします。 システム リソースが飽和状態になっていない場合は、ここで説明する手順を実行します。
受信場所のボトルネック
受信場所でメッセージが蓄積され始めている場合 (ファイル受信フォルダーのサイズが大きくなっている場合や、送信キューの排出が遅い場合など) は、システムがデータを取り込む速度が不十分なため、受信の負荷に対応できていないことを示します。その原因としては内部の制限が考えられます (BizTalk では、サブスクライバーのデータ処理の遅れによりデータベース テーブルにバックログが蓄積されると、受信速度が低減されます)。 ボトルネックの原因がハードウェアの制限にある場合は、スケール アップを試みます。 受信ハンドラーにマップされているホストにホスト インスタンス (サーバー) を追加することによってスケール アウトすることもできます。 Perfmon を使用して、システムのリソース使用率を監視します。 ボトルネックの原因が外部の受信場所でないことを確認することが重要です。 たとえば、頻繁なディスク入出力によってリモートのファイル共有が飽和状態になっていないか、リモートの送信キューをホストしているサーバーが飽和状態になっていないか、HTTP/SOAP の負荷を生成するために使用されているクライアントでスレッドが不足していないかなどを確認します。
処理のボトルネック
Host Queue - Length のカウント (以下の Perfmon カウンターの表を参照) が高くなっている場合は、オーケストレーションの完了が遅れています。 この原因としては、メモリの競合や CPU の飽和が考えられます。
オーケストレーション サーバーがボトルネックになっている場合は、Perfmon を使用して原因を特定します。
サーバーが CPU の制約を受けている場合は、以下の対策を検討します。
ワークフローが複雑な場合は、オーケストレーションを複数の小さなオーケストレーションに分割することを検討します。
注意
オーケストレーションを複数のワークフローに分割すると、待機時間が増加したり複雑さが増したりする可能性があります。
複雑なマップが使用されている場合は、受信ポートか送信ポートに移動できないかどうかを検討します (どちらのポートが帯域幅に余裕があるかを確認してください)。
ハードウェアのスケール アップを検討するか、可能であれば、追加の処理サーバーを構成してスケール アウトすることを検討します。
送信のボトルネック
送信サーバーでリソース (ディスク、メモリ、CPU など) が飽和状態になっている場合は、サーバーのスケール アップを検討するか、可能であれば、送信ホスト サーバーを追加してスケール アウトすることを検討します。 送信層がボトルネックになる場合、送信先 (BizTalk の外部) でのデータの受信が遅れている可能性もあります。 送信先でのデータの受信が遅れると、メッセージ ボックス データベース (Application SendHostQ) にメッセージが蓄積されます。
すべてのエンドポイントがトポロジの範囲内にある場合は、原因を送信先で切り分けることを検討します。 たとえば、HTTP/SOAP の場所が負荷を受け取るのに最適な構成になっているか、スケールアウトが可能か、 BizTalk によって配信される出力メッセージが多すぎるために送信先でメッセージが蓄積されていないかを確認します。 送信先でメッセージが蓄積されている場合は、送信先のメッセージのアーカイブや削除を行うメンテナンス プランを検討します。 たとえば、送信先のフォルダーに多数のファイルがあると、BizTalk サービスによるディスク ドライブへのデータのコミットに深刻な影響を及ぼす可能性があります。
追跡のボトルネック
追跡ホスト インスタンスには、BAM および追跡メッセージ イベントとサービス インスタンスのデータの両方を、メッセージ ボックス データベース (TrackingData テーブル) から BizTalkDTADb データベースや BAMPrimaryImport データベースのテーブルに移動する役割があります。 複数のメッセージ ボックス データベースが構成されている場合、追跡ホスト インスタンスはメッセージ ボックスごとに 4 つのスレッドを使用します。
このホスト インスタンスが CPU の制約を受けている可能性があります。 その場合は、サーバーをスケール アップするか、ホストの追跡を有効にした追加のサーバーを構成してスケール アウトすることを検討します。 複数のホスト インスタンスによって、複数構成のメッセージ ボックスの負荷が自動的に分散されます。
メッセージ ボックス データベースの TrackingData テーブルでバックアップが開始されている場合は、通常、BizTalkDTADb データベースや BAMPrimaryImport データベースのデータ管理ジョブが構成されたとおりに実行されていないため、データベースのサイズが増加しています。 これらのデータベースのサイズが大きくなりすぎると、それらのテーブルにデータを挿入する追跡ホストの機能に悪影響を及ぼし、追跡データがメッセージ ボックス データベースのテーブルにバックアップされることになります。 MessageBox-TrackingData> テーブルの増加により、調整が開始されます。
その他
さまざまな機能がそれぞれ専用の分離ホスト インスタンスで実行されるように展開トポロジを構成します。 これにより、各ホスト インスタンスにそれぞれ固有のリソースのセット (32 ビット システムの場合は 2 GB の仮想メモリ アドレス空間、ハンドル、スレッドなど) が割り当てられます。 サーバーに複数のホスト インスタンスをホストする余力がある (CPU ヘッドルームやメモリが十分にある) 場合は、すべてのホスト インスタンスを同じ物理コンピューターで実行するように構成できます。 そうでない場合も、機能を専用のサーバーに移動することにより容易にスケール アウトすることができます。 同じ機能を複数のサーバーで実行すると、高可用性の構成を実現することもできます。
BizTalk システム パフォーマンス カウンター
| Object | インスタンス | カウンタ | 監視の目的 |
|---|---|---|---|
| プロセッサ | _Total | % Processor Time | リソースの競合 |
| Process | BTSNTSvc | Virtual Bytes | メモリ リーク/メモリの肥大化 |
| Process | BTSNTSvc | Private Bytes | メモリ リーク/メモリの肥大化 |
| Process | BTSNTSvc | ハンドルの数 | リソースの競合 |
| Process | BTSNTSvc | Thread Count | リソースの競合 |
| 物理ディスク | _Total | % Idle Time | リソースの競合 |
| 物理ディスク | _Total | Current Disk Queue Length | リソースの競合 |
CPU の競合
プロセッサが飽和状態の場合は、送信とオーケストレーションから受信を分離して、アプリケーションをフラグメント化することを検討します。 そのためには、別々のホストを作成して特定の機能 (受信、送信、オーケストレーション、追跡) にマップし、それぞれに専用のサーバーを追加します。 一般に、オーケストレーションは CPU を大量に消費します。したがって、オーケストレーションを別の専用サーバーで実行するようにシステムを構成すると、システム全体のスループットが向上します。
複数のオーケストレーションが展開されている場合は、それぞれを異なる専用オーケストレーション ホストに参加させることができます。 それらの専用オーケストレーション ホストに別々の物理サーバーをマップすると、それぞれのオーケストレーションが分離されるため、同じ物理アドレス空間または同じサーバーで共有されているリソースの競合が発生しなくなります。
メモリ不足
高スループットのシナリオでは、システム メモリの需要が増大する場合があります。 32 ビット プロセスでは、使用できるメモリの量が制限されているため、受信、処理、送信の機能をそれぞれ別のホスト インスタンスに分離して、各ホストに 2 GB のアドレス空間が割り当てられるようにすることをお勧めします。 さらに、同じ物理サーバー上で複数のホスト インスタンスが実行されている場合は、実際のメモリからディスクにデータをスワップする必要がないように、4/8 GB メモリにアップグレードすると便利です。 実行時間の長いオーケストレーションでは、割り当てられたメモリが長く保持され、メモリが肥大化し、調整が開始される可能性があります。 メッセージが大きいと、メモリ消費量が多くなる場合もあります。
特定のホストの CPU 値あたりの内部メッセージ キュー サイズとインプロセス メッセージを下げることで、大きなメッセージが処理されている場合に、このメモリの肥大化の問題を克服できます。
ディスクの競合
ディスクが飽和している場合 (ファイル/MSMQ トランスポートなど)、複数のスピンドルにアップグレードし、RAID 1+0 でディスクをストライピングすることを検討してください。 さらに、FILE トランスポートを使用する場合は常に、フォルダー (受信と送信の両方) が大きくなりすぎないようにすることが重要です (>50,000 ファイル)。
BizTalk Server では、以下で説明するさまざまな理由によりシステムの受信データが制限された場合、受信フォルダーのサイズが大きくなることがあります。 また、送信フォルダーのサイズが大きくなると、BizTalk Server による追加データの書き込みに影響を及ぼす可能性もあるため、送信フォルダーからデータを移動することも重要です。 非トランザクション MSMQ キューについては、BizTalk Server のディスクの競合を減らすため、受信キューをリモートに作成することをお勧めします。
この構成 (リモートの非トランザクション キュー) では、キューをホストするリモート サーバーのクラスター化が可能になるため、高可用性のメリットもあります。
その他のシステム リソースの競合
構成されているトランスポートの性質によっては、IIS のようなシステム リソースを HTTP/SOAP 用に構成する必要がある場合もあります (MaxIOThreads や MaxWorkerThreads など)。
下流のボトルネック
下流システムが BizTalk からのデータを十分な速さで受信できない場合、その出力データが BizTalk データベースにバックアップされます。その結果、データベースが肥大化して制限が作動し、受信パイプが縮小されるため、BizTalk システム全体のスループットに影響します。 この状況を直接示すのはスプールの増大です。
制限の影響
システムが回復不可能な状態にならないように、最終的には制限が作動します。 したがって制限は、システムが正常に機能しているかどうかを確認し、問題の原因を特定するための場所として適しています。 制限の状態からボトルネックの原因を特定できたら、他のパフォーマンス カウンターを分析して問題の原因にドリル ダウンします。
たとえば、メッセージ ボックス データベースで競合が増加している場合、その原因としては CPU 使用率の増加が考えられます。さらに、CPU 使用率の増加の原因としてはディスクへの過剰なページングが、その原因としてはメモリの不足が、それぞれ考えられます。 メッセージ ボックスで競合が増加する原因としては、その他にロックの競合の増加も考えられます。ロックの競合が増加する原因としては、ディスク ドライブが飽和状態になっていることが考えられます。
BizTalk アプリケーション カウンター
| Object | インスタンス | カウンタ | 説明 |
|---|---|---|---|
| BizTalk Messaging | RxHost | Documents Received/Sec | 受信速度 |
| BizTalk Messaging | TxHost | Documents Processed/Sec | 送信速度 |
| XLANG/s Orchestrations | PxHost | Orchestrations Completed/Sec. | 処理率 |
| BizTalk : MessageBox: 全般カウンター | MsgBoxName | Spool Size | すべてのホスト キューの合計サイズ |
| BizTalk : MessageBox: 全般カウンター | MsgBoxName | Tracking Data Size | メッセージ ボックスの TrackingData テーブルのサイズ |
| BizTalk:MessageBox:Host Counters | PxHost:MsgBoxName | Host Queue - Length | 特定のホスト キューに存在するメッセージの数 |
| BizTalk:MessageBox:Host Counters | TxHost:MsgBoxName | Host Queue - Length | 特定のホスト キューに存在するメッセージの数 |
| BizTalk:Message Agent | RxHost | データベース サイズ | 公開 (PxHost) キューのサイズ |
| BizTalk:Message Agent | PxHost | データベース サイズ | 公開 (TxHost) キューのサイズ |
| BizTalk:Message Agent | HostName | Message Delivery Throttling State | XLANG と送信トランスポートに影響 |
| BizTalk:Message Agent | HostName | Message Publishing Throttling State | XLANG と受信トランスポートに影響 |
どこから始めるか
通常、各ホスト インスタンスの メッセージ配信調整状態 と メッセージ発行調整状態 の監視は、開始するのに適した場所です。 これらのカウンターの値が 0 でない場合、BizTalk システム内で制限が発生していることがわかります。そこから、ボトルネックの原因をさらに分析することができます。 その他のパフォーマンス カウンターの説明については、「 パフォーマンスのボトルネックの特定」を参照してください。
バックログの蓄積
1 つの受信メッセージに対して 1 つの処理と送信が行われる 1 対 1 の展開シナリオで、送信速度が受信速度と等しくない場合は、システムのどこかでバックログが蓄積されています。 そのような場合は Spool Size を監視します。
Spool Size が直線的に増加している場合は、その原因がどのアプリケーション キューにあるのかを確認することによって、さらにドリル ダウンを進めることができます。
サイズが増加しているアプリケーション キューがないのに Spool Size が増加し続けている場合は、Purge ジョブの処理が追いついていない可能性があります。その原因としては、エージェントが実行されていないか、SQL Server で他のシステム リソースが競合していることが考えられます。
サイズが増加しているアプリケーション キューがある場合は、その増加の原因を診断することが重要です。 そのアプリケーション キューの排出ができなくなっているシステムでシステム リソースを監視します (たとえば、サーバーの CPU が不足すると Orchestration Host-Q のサイズが増加します)。 さらに、そのホスト インスタンスの制限カウンターの値を確認します。
Delivery/Publishing State が 0 でない場合は、値を調べて制限の原因を確認します (たとえば、メモリのしきい値を超えている場合や、インフライト メッセージの数が多すぎる場合などが考えられます)。
F1 Profiler
パフォーマンス カウンターを使用すると、ボトルネックのだいたいの場所をすばやく特定できます。 しかし、場所が絞り込んだ後、問題を解消するにはさらにコードにドリル ダウンする必要がある場合もあります。 Visual Studio に付属の F1 Profiler は、コードのサイクルが最も消費されている場所を診断するのに非常に便利なツールです。
シンボルは、より意味のあるスタックを作成するうえで (アンマネージ コードの場合は特に) 重要です。 たとえば F1 Profiler では、API 呼び出しが戻るまでに要する呼び出しの数や時間を特定できます。 スタックをさらにドリル ダウンすることによって、待機時間の増加の根本原因を特定できる場合もあります。 たとえば、データベース クエリへのブロッキング呼び出しが原因になっている場合や、呼び出しがイベントを待機しているだけである場合などがあります。
L2/L3 キャッシュ
ハードウェアの観点からは、オンボードの CPU キャッシュを利用した場合に、最も大きな効果が得られます。 CPU キャッシュが大きければキャッシュのヒット率が高くなり、システムでメモリからディスクへのデータのページングを行う必要が少なくなります。
64 ビットのパフォーマンスのボトルネック
64 ビット システムのパフォーマンスが 32 ビット システムより低く見える場合があります。 原因はいくつか考えられますが、最も重要な原因はメモリです。
2 GB のメモリを搭載した 32 ビット システムでパフォーマンスを測定し、その結果を 2 GB のメモリを搭載した同様の 64 ビット システムと比較する場合、厳密には同じ条件の比較にはなりません。 64 ビット システムがディスク入出力の制約を受けていたり (% Disk Idle time が低く、Disk Queue Length が高い)、CPU の制約を受けていたり (CPU が上限に達し、Context Switching も高い) するように見えますが、 これは、64 ビット システムのファイル入出力処理により多くのリソースが必要とされるということではありません。
64 ビット システムはより多くのメモリを必要とするため (64 ビット アドレッシング)、使用可能な 2 GB のメモリのほとんどが OS によって使用されます。 そのため、他のほとんどの操作でディスクへのページングが発生し、ファイル サブシステムに負荷がかかります。 結果として、データとコードの両方のページングに CPU サイクルが消費されるだけでなく、ディスクの待機時間も増加します。 それが、ディスクの競合と CPU 消費の増加として現れます。
この問題を解消するには、メモリを (できれば 8 GB に) アップグレードしてサーバーをスケールアップします。 ただし、問題の原因がメモリ不足に起因する CPU 不足でない場合は、メモリを追加してもスループットは向上しません。
BAM によるボトルネックと待機時間の問題の特定
待機時間の短縮が重視される場合は、BAM を使用すると、BizTalk システム内の各ステージの完了にかかる時間を測定できます。 追跡されたメッセージ イベントとサービス インスタンス データを使用してメッセージの状態をデバッグし、メッセージのルーティングに関する問題の原因を診断できますが、BAM を使用してメッセージ フローを介してさまざまなポイントを追跡できます。 BAM 追跡プロファイルを作成することにより (継続を含むアクティビティを定義します)、システムのさまざまな部分の間の待機時間を測定して、ワークフロー プロセス内で最もコストの大きいステージを追跡できます。