BizTalk Server は永続的なシステムとして設計されています。 高スループットのシナリオでは、MessageBox データベースと BizTalk Tracking データベースで重大な競合が発生する可能性があります。 この競合は、低速ディスクによって悪化する可能性があります。 ディスクが低速の場合 (平均ディスク秒/読み取りまたは平均ディスク秒/書き込みで平均 15 ミリ秒を超える)、SQL Server がロックを長く保持する可能性があります (ロック待機時間が長く、ロックタイムアウトが大きい)。 これにより、MessageBox テーブル (Spool および Application Queues) が拡大し、データベースの肥大化と制限が発生する可能性があります。 この状況により、最終的に全体的な持続可能なスループットが低下します。
注
サーバーにディスクのボトルネックがあるかどうかを特定する方法については、「 Windows パフォーマンス モニター (https://go.microsoft.com/fwlink/?LinkID=204007)」を参照してください。 Windows パフォーマンス モニターは、システム パフォーマンスを分析するためのツールを提供する Microsoft 管理コンソール (MMC) スナップインです。
ディスクの競合を回避するには、次の操作を行います。
| ステップス | リファレンス |
|---|---|
| Raid10/0+1 ディスク構成を使用します。 | ボトルネックを回避するためのベスト プラクティス |
| 可能であれば、高速 SAN にデータベースをデプロイします。 複数のデータベースが同じディスクを共有している場合は、個別の 専用 ディスクに構成することをお勧めします。 さらに、MessageBox データベースの MDF ファイルと LDF ファイルを別々のディスクに分離することをお勧めします。 | Databases2 のファイル グループの最適化 |
| TEMPDB データベースに複数のファイルを割り当てることを検討してください。これにより、ディスクの競合が大幅に軽減され、複数のデータ ファイルに負荷が分散されるためです。 | 構成前データベースの最適化 2 |
| メッセージ ボックス データベースを、BizTalk 追跡データベースとは別の専用サーバーに分離することを検討してください。 | 構成後のデータベースの最適化 2 |
| MSDTC ログ ファイル ディレクトリを別の専用ドライブに割り当てます。 | オペレーティング システムのパフォーマンスの最適化 |
| PageFile または MSDTC ログが原因でローカル ドライブで競合が発生した場合は、PageFile ログまたは MSDTC ログを別のドライブに移動してみてください。 | ボトルネックを回避するためのベスト プラクティス |
| 書き込み操作用に追跡データベースを最適化します。 | 追跡データベースのボトルネックを特定する方法 |
| 読み取り操作と書き込み操作用に MessageBox データベースを最適化します。 | MessageBox Database1 のボトルネックを特定する方法 |
| BizTalk ホスト インスタンスが CPU を飽和状態にしている場合は、送信、受信、処理、追跡機能を複数のホストに分離することを検討してください。 これにより、オーケストレーション機能が個別の専用サーバーで実行され、システム全体のスループットが向上するようにシステムが構成されます。 | BizTalk Server のパフォーマンスの最適化 |
| 複数のオーケストレーションが展開されている場合は、それらを別の専用オーケストレーション ホストに参加することを検討してください。 これにより、異なるオーケストレーションが分離され、同じ物理アドレス空間または同じサーバー上の共有リソースの競合が回避されます。 | BizTalk Server のパフォーマンスの最適化 |
| Windows パフォーマンス モニターを使用してディスクの競合の問題を診断することを検討してください。 | Windows パフォーマンス モニター |
ディスク パフォーマンス分析の詳細については、次のリソースを参照してください。
SQL Server 2008 でのパフォーマンスの問題のトラブルシューティングに関するセクションの「I/O ボトルネック」セクション。