次の方法で共有

BizTalk Server 層のボトルネック

  • [アーティクル]

BizTalk 層は以下の機能領域に分割できます。

  • 受信

  • 処理中

  • 送信

  • 追跡

  • その他

    これらの領域では、システム リソース (CPU、メモリ、ディスク) が飽和状態になっているように見える場合は、アプリケーションの特性に基づいてプラットフォームをスケールアップまたはスケールアウトしてサーバーをアップグレードします。 システム リソースが飽和状態になっていない場合は、ここで説明する手順を実行します。

受信場所のボトルネック

メッセージが受信場所に蓄積された場合 (たとえば、ファイル受信フォルダーが大きくなる場合)、システムが受信負荷に対応するのに十分な速度でデータを吸収できないことを示します。 これは、内部調整が原因です。 つまり、サブスクライバーがデータを十分に高速に処理できない場合、BizTalk Serverは受信速度を低下させ、データベース テーブルでバックログの蓄積が発生します。 ボトルネックがハードウェアの制限によって引き起こされている場合は、スケールアップを試してください。 スケールアップの詳細については、BizTalk Server 2010 ドキュメントの次のトピックを参照してください。

処理のボトルネック

ホスト キュー – 長さのパフォーマンス カウンターが上昇している場合は、オーケストレーションが十分に高速に完了していないことを示します。 詳細については、このトピックの「Perfmon カウンター」の表を参照してください。 この原因としては、メモリの競合や CPU の飽和が考えられます。

オーケストレーション サーバーがボトルネックになっている場合は、Perfmon を使用して原因を特定します。

サーバーが CPU の制約を受けている場合は、以下の対策を検討します。

  • ワークフローが複雑な場合は、オーケストレーションを複数の小さなオーケストレーションに分割することを検討してください

    注意

    オーケストレーションを複数のワークフローに分割すると、待機時間が増加したり複雑さが増したりする可能性があります。 また、複数のワークフローを使用すると、BizTalkMsgBoxDb との間で発行および使用されるメッセージの数が増加し、データベースに負荷が加わる可能性があります。

  • 複雑なマップを使用する場合は、受信/送信ポートに移動できるかどうかを検討してください。 追加の帯域幅を持つポートを確認してください。

  • ハードウェアをスケールアップするか、追加の処理サーバーを構成してスケールアウトすることを検討してください。

ボトルネックの送信

送信アダプターをホストしているサーバーがリソース (ディスク、メモリ、CPU など) で飽和状態になっている場合は、サーバーをスケールアップするか、追加の送信ホスト サーバーにスケールアウトすることを検討してください。 送信層がボトルネックになる場合、送信先 (BizTalk の外部) でのデータの受信が遅れている可能性もあります。 送信先でのデータの受信が遅れると、メッセージ ボックス データベース (Application SendHostQ) にメッセージが蓄積されます。

すべてのエンドポイントがトポロジのスコープ内にある場合は、宛先で原因を分離します。 たとえば、HTTP の場所が読み込みを受信するように最適に構成されているかどうかを判断します。 そうでない場合は、スケールアウトを検討してください。また、BizTalk によって配信される過剰な出力メッセージが原因で宛先が拡大しているかどうかを判断します。 はい場合は、宛先メッセージをアーカイブして消去するためのメンテナンス プランが必要になる場合があります。 コピー先フォルダー内の多数のファイルは、BizTalk サービスがディスク ドライブにデータをコミットする機能に大きな影響を与える可能性があります。

ボトルネックの追跡

Tracking ホスト インスタンスは、Business Activity Monitoring (BAM) と Health and Activity Tracking (HAT) のデータを MessageBox データベース (TrackingData テーブル) から BizTalk Tracking または BAM プライマリ インポート データベース テーブルに移動する役割を担います。 複数の MessageBox データベースが構成されている場合、追跡ホスト インスタンスは MessageBox データベースごとに 4 つのスレッドを使用します。

追跡ホスト インスタンスが CPU バインドされている可能性があります。 その場合は、ホスト追跡を有効にして追加のサーバーを構成して、サーバーのスケールアップまたはスケールアウトを検討してください。 複数のホスト インスタンスは、構成された複数の MessageBox データベースの負荷分散を自動的に行います。 スケーリングの詳細については、「 ソリューションのスケーリング (https://go.microsoft.com/fwlink/?LinkId=158078)」を参照してください。

MessageBox データベースの TrackingData テーブルが大きくなる場合、通常は、BizTalk Tracking データベースまたは BAM プライマリ インポート データベースのデータ メンテナンス ジョブが構成どおりに実行されていないため、BizTalk Tracking データベースまたは BAM プライマリ インポート データベースが増加します。 これらのデータベースが大きくなりすぎると、Tracking ホストが TrackingData テーブルにデータを挿入する機能に悪影響を及ぼす可能性があります。 これにより、追跡されたデータが MessageBox データベース テーブルにバックアップされます。 TrackingData テーブルの増加により、調整が開始されます。

アプリケーションに必要な最小限の追跡のみを有効にする必要があります。これにより、ログに記録されるデータの量が減り、ボトルネックを追跡するリスクが軽減されるためです。 オーケストレーションや送受信ポートなどの個々の項目の追跡設定を無効にする方法については、「 追跡を無効にする方法 (https://go.microsoft.com/fwlink/?LinkId=160064)」を参照してください。

その他

さまざまな機能がそれぞれ専用の分離ホスト インスタンスで実行されるように展開トポロジを構成します。 これにより、各ホスト インスタンスは、独自のリソースセット (32 ビット システムでは 2 GB の仮想メモリ アドレス空間、ハンドル、スレッドなど) を取得します。 サーバーに複数のホスト インスタンスをホストするのに十分な CPU ヘッドルームとメモリがある場合は、同じ物理コンピューター上で実行するように構成できます。 そうでない場合は、機能を専用サーバーに移動してスケールアウトすることを検討してください。 同じ機能を複数のサーバーで実行すると、高可用性の構成を実現することもできます。

BizTalk システム パフォーマンス カウンター

Object インスタンス カウンタ 監視の目的
プロセッサ _Total % Processor Time リソースの競合
Process BTSNTSvc Virtual Bytes メモリ リーク/メモリの肥大化
Process BTSNTSvc Private Bytes メモリ リーク/メモリの肥大化
Process BTSNTSvc ハンドルの数 リソースの競合
Process BTSNTSvc Thread Count リソースの競合
物理ディスク _インスタンス % Idle Time リソースの競合
物理ディスク _インスタンス Avg. Disk Queue Length リソースの競合

CPU 競合

プロセッサが飽和状態の場合は、送信側とオーケストレーションから受信を分離することで、アプリケーションをフラグメント化できます。 これを行うには、個別のホストを作成し、ホストを特定の機能 (受信/送信/オーケストレーション/追跡) にマップし、専用サーバーをこれらの個別のホストに追加します。 オーケストレーション機能は、多くの場合、CPU 負荷が高くなります。 オーケストレーションが別の専用サーバーで実行されるようにシステムを構成すると、システム全体のスループットを向上させることができます。

複数のオーケストレーションがデプロイされている場合は、それらを別の専用オーケストレーション ホストに参加させることができます。 異なる物理サーバーを専用オーケストレーション ホストにマッピングすると、異なるオーケストレーションが分離され、同じ物理アドレス空間または同じサーバー上の共有リソースに対して競合しないようにすることができます。

未使用のホスト インスタンスを停止します。 未使用のホスト インスタンスは、メッセージ ボックスで処理するメッセージを定期的にチェックすることで、CPU リソースとメモリ リソースを競合させることができます。 さらに、未使用の受信場所、送信ポート、オーケストレーションを停止します。

スプール テーブルの増加

ダウンストリームのボトルネックやリソースの競合により、スプールが過剰に増加し始め、全体的なパフォーマンスが低下する可能性があります。 詳細については、「 MessageBox Database1 のボトルネックを特定する方法」の「スプール テーブルの増加」を参照してください。

メモリ不足

高スループットのシナリオでは、システム メモリの需要が増大する場合があります。 32 ビット プロセスは消費できるメモリの量によって制限されるため、受信/プロセス/送信機能を個別のホスト インスタンスに分離し、各ホストが独自の 2 GB アドレス空間を受信するようにすることをお勧めします。 さらに、同じ物理サーバーで複数のホスト インスタンスが実行されている場合は、4/8 GB のメモリにアップグレードして、実際のメモリからデータをディスクにスワップしないようにすることができます。 実行時間の長いオーケストレーションでは、割り当てられたメモリを長く保持できます。 これにより、メモリの肥大化と調整が開始される可能性があります。 メッセージが大きいと、メモリ消費量が多くなる場合もあります。

特定のホストの CPU あたりの 内部メッセージ キュー サイズ と インプロセス メッセージの値を下げることで、大きなメッセージが処理されるときに発生するメモリの肥大化の問題を軽減できます。

注意

待機時間が懸念される場合は、システムのエンドツーエンドの待機時間が長くなる可能性があるため、CPU あたりの 内部メッセージ キュー サイズ と インプロセス メッセージ に対する変更は注意して行う必要があります。

ディスクの競合

ディスクが飽和している場合 (たとえば、多数の FILE/MSMQ トランスポートがある場合)、複数のスピンドルにアップグレードし、RAID 10 でディスクをストライピングすることを検討してください。 さらに、FILE トランスポートを使用するときは常に、受信フォルダーと送信フォルダーが 50,000 ファイルを超えないようにすることが重要です。

受信フォルダーは、BizTalk Serverがシステムに受信データを調整すると、大きくなる可能性があります。 このフォルダーの増加が追加のデータを書き込むBizTalk Serverの機能に影響を与えないように、送信フォルダーからデータを移動することが重要です。 非トランザクション MSMQ キューの場合は、BizTalk Serverでディスクの競合が減るように、リモートで受信キューを作成することをお勧めします。

また、リモート非トランザクション キュー構成では、キューをホストしているリモート サーバーをクラスター化できるため、高可用性も提供されます。

その他のシステム リソースの競合

トランスポートの種類によっては、HTTP 用の IIS などのシステム リソース (MaxIOThreads、MaxWorkerThreads など) を構成する必要がある場合があります。

ASP.NET 2.0 と ASP.Net 4 では、 <machine.config ファイルの processModel autoConfig="true"> 設定によって、最適なパフォーマンスを得るための次の設定が自動的に構成されます。

  • ワーカー スレッドの最大数

  • 最大 IO スレッド数

  • httpRuntime 要素の minFreeThreads 属性

  • httpRuntime 要素の minLocalRequestFreeThreads 属性

  • connectionManagement> 要素 (ネットワーク設定) 要素の <maxConnection 属性

    アダプターのパフォーマンスに影響を与えるパラメーターの構成の詳細については、「 processModel 要素 ASP.NET 構成設定 (https://go.microsoft.com/fwlink/?LinkId=158080)」を参照してください。

    BizTalk Server アダプターに影響を与える可能性がある構成設定の詳細については、「アダプターのパフォーマンスに影響を与える構成パラメーター (https://go.microsoft.com/fwlink/?LinkID=154200)」を参照してください。

    BizTalk Server アプリケーションの最適化に加えて、同じサーバーで実行されている他の ASP.NET アプリケーションは、全体的なパフォーマンスに影響を与える可能性があります。 システム リソースに対する需要を減らすために、すべての ASP.NET アプリケーションを最適化することが重要です。 詳細については、「 ASP.NET パフォーマンス (https://go.microsoft.com/fwlink/?LinkId=158081)」を参照してください。

    最大限のパフォーマンスを得るように構成する場合は、BizTalk ソリューション全体の一部であるメッセージング エンジン (メッセージ キュー、MQSeries)、アプリケーション、データベース、Active Directory など、他の外部システムを最適化することを検討してください。 これらの他の外部システムのパフォーマンスのボトルネックは、BizTalk ソリューションに悪影響を及ぼす可能性があります。

ダウンストリームのボトルネック

ダウンストリーム システムが BizTalk から十分な速度でデータを受信できない場合、この出力データは BizTalk データベースにバックアップされます。 これにより、肥大化が発生し、調整が開始され、受信パイプが縮小され、BizTalk システムの全体的なスループットに影響します。 この直接の兆候は、スプール テーブルの増加です。 ボトルネックと Spool テーブルの詳細については、「 How to Identify Bottlenecks in the MessageBox Database1」を参照してください。

調整の影響

調整は最終的に開始され、システムが回復不可能な状態に達するのを防ぎ始めます。 そのため、調整を使用して、システムが正常に機能しているかどうかを確認し、問題の原因を検出できます。 調整状態からのボトルネックの原因を特定したら、他のパフォーマンス カウンターを分析して問題の原因を特定します。 たとえば、メッセージ ボックス データベースの競合が高いのは、CPU 使用率が高いことが原因で発生する可能性があります。これは、メモリ不足の状態が原因でディスクに過剰にページングされていることが原因です。 MessageBox データベースの競合が高い場合は、ディスク ドライブの飽和によるロックの競合が高い場合もあります。 不定期の調整はパフォーマンスに対する重大な脅威ではありませんが、永続的な調整は、より重大な根本的な問題を示す可能性があります。 BizTalk Serverが調整を使用する条件の詳細については、「BizTalk Serverホスト調整を実装する方法 (https://go.microsoft.com/fwlink/?LinkID=155286)」を参照してください。

BizTalk Server調整が使用可能なリソースの使用を管理し、リソースの競合を最小限に抑える方法の詳細については、「ホスト調整によるリソース使用量の最適化 (https://go.microsoft.com/fwlink/?LinkID=155770)」を参照してください。

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 システムでの調整を示し、ボトルネックの原因をさらに分析できます。 その他のパフォーマンス カウンターの説明については、「 データベース層のボトルネック」を参照してください。

オーケストレーション エンジンのパフォーマンス カウンター

継続的オーケストレーションの脱水とリハイドレートと永続化ポイントは全体的なパフォーマンスに重大な影響を与える可能性があるため、オーケストレーション ランタイム設定を微調整することを強くお勧めします。 複数の永続化ポイントとトランザクション スコープを含む可能性がある複雑なオーケストレーションをテストする場合は、次のカウンターを使用する必要があります。

カウンタ 説明
Orchestrations dehydrated/sec 1 秒あたりの平均待避数。
Orchestrations rehydrated/sec 1 秒あたりの平均復元数。
Persistence points/sec 永続化されたオーケストレーション インスタンスの 1 秒あたりの平均数。
Orchestrations resident in memory ホスト インスタンスによって現在ホストされているオーケストレーション インスタンスの数。
Orchestrations completed/sec 1 秒あたりの平均完了数。
Orchestrations suspended/sec 1 秒あたりの平均中断数。
Transactional scopes committed/sec 1 秒あたりの平均コミット数。
Transactional scopes aborted/sec 1 秒あたりの平均中止数。
Transactional scopes compensated/sec 1 秒あたりの平均補正数。

バックログのビルドアップ

1-1 の展開シナリオでは、1 つのメッセージが受信され、1 つのメッセージが処理および送信されます。送信レートが受信レートと等しくない場合は、システムにバックログがあります。 このような場合は、スプール サイズを監視できます。 送信レートのボトルネックの原因を特定する場合は、一度に 1 つのユース ケース シナリオを実行します。 オーケストレーションを分離し、場所を受信し、別のホストに場所を送信します。

BizTalk:Message Box:Host Counters をパフォーマンス モニター ログに追加して、ホストを監視します。 ホスト キュー - 長さ: カウンターは、特定のホスト キュー内のメッセージの合計数を追跡します。 これらのカウンターの 1 つ以上が時間の経過と同時に増加し続ける場合は、それらのホストによって実行される成果物に特に注意してください。

スプールが直線的に増加している場合は、スプールの拡張を担当するアプリケーション キューを決定します。

どのアプリケーション キューも増え続けず、スプールが増加し続ける場合は、消去ジョブが追いつくことができない可能性があります。 これは、エージェントが実行されていない場合、またはSQL Serverで他のシステム リソースの競合が発生した場合に発生します。

いずれかのアプリケーション キューが増加している場合は、この増加の原因を診断します。 特定のアプリケーション キューをドレインできないシステム上のシステム リソースを監視します (たとえば、サーバーの CPU 不足が原因でオーケストレーション ホスト Q が増加しています)。 さらに、特定のホスト インスタンスの調整カウンターの値を確認します。

BizTalk:Message Agent のメッセージ配信調整状態とメッセージ発行の調整状態のパフォーマンス カウンターが 0 でない場合は、値をチェックして調整の理由を確認します (たとえば、メモリしきい値を超えた、進行中のメッセージ数が多すぎるなど)。

Stand-Alone Profiler

パフォーマンス カウンターを使用して、ボトルネックの場所を大まかに検出できます。 ただし、絞り込んだ後は、問題を緩和するために、コードをより詳しく調べる必要がある場合があります。 Visual Studio 2010 に付属する Stand-Alone Profiler は、コードがほとんどのサイクルを費やしている場所を診断するのに役立つ非常に便利なツールです。 詳細については、「

L2/L3 キャッシュ

ハードウェアの観点からは、オンボード CPU キャッシュを使用することで最大の利点を得ることができます。 CPU キャッシュが大きければキャッシュのヒット率が高くなり、システムでメモリからディスクへのデータのページングを行う必要が少なくなります。

64 ビット パフォーマンスのボトルネック

64 ビット システムのパフォーマンスが 32 ビット システムより低く見える場合があります。 これはいくつかの理由で可能です。最も重要なものはメモリです。

2 GB のメモリを持つ 32 ビット システムのパフォーマンスを測定し、結果を 2 GB のメモリを持つ同様の 64 ビット システムと比較することは、同じものではありません。 64 ビット システムは、ディスク I/O バインド (ディスク アイドル時間が短い & ディスク キューの長さが高い) と CPU バインド (最大 CPU と高コンテキスト切り替え) のように見えます。 ただし、これは、64 ビット システムでファイル I/O を実行する方がコストが高いためではありません。

64 ビット システムの方がメモリを大量に消費する (64 ビット アドレス指定) ため、オペレーティング システムは 2 GB の使用可能なメモリの大部分を消費します。 この場合、他のほとんどの操作では、ファイル サブシステムを負荷するディスクへのページングが発生します。 そのため、システムはデータとコードの両方のメモリのページングに CPU サイクルを費やし、ディスク待機時間の高いコストの影響を受けます。 それが、ディスクの競合と CPU 消費の増加として現れます。

この問題を軽減する方法は、メモリをアップグレードしてサーバーをスケールアップすることです。 ただし、8 GB へのスケールアップは考え方ですが、メモリが不足しているため、問題の原因が CPU 不足でない限り、メモリを追加するとスループットが向上しません。

BAM を使用してボトルネックと待機時間の長い問題を特定する

低待機時間が重要な場合は、BAM を使用して、BizTalk Server システム内の各ステージの完了にかかる時間を測定できます。 HAT を使用してメッセージの状態をデバッグし、メッセージのルーティングに関する問題の原因を診断できますが、BAM を使用してメッセージ フローを通じてさまざまなポイントを追跡できます。 継続を含むアクティビティを定義する BAM 追跡プロファイルを作成することで、システムのさまざまな部分間の待機時間を測定して、ワークフロー プロセス内で最もコストの高いステージを追跡できます。

HAT のオーケストレーション デバッガーを使用すると、中断されたインスタンスのクエリを実行し、デバッグ モードでインスタンスを再開し、技術詳細ビューを使用して適切なブレークポイントを追加できます。 これにより、動作とデバッグ メッセージをステップごとにトレースすることができます。

ブレークポイントを設定して以下のイベントを追跡することができます。

  • オーケストレーションの開始と終了

  • 図形の開始と終了

  • メッセージの送信と受信

  • 例外

    各ブレークポイントで、ローカル変数、メッセージとそのプロパティ、ポート、およびロール リンクに関する情報を調べることができます。

参照

ボトルネックの検索と解消