ボトルネックを回避するためのベスト プラクティス
BizTalk Serverの既定の設定は、多くのハードウェアとソフトウェアの構成に最適なパフォーマンスを提供しますが、一部のシナリオでは、設定または展開の構成を変更すると便利な場合があります。 BizTalk Serverを構成する場合は、次のパフォーマンス ガイドラインを考慮してください。
リソースの競合を防ぐために、受信、オーケストレーション、および個別のホストでの送信を分離します。 競合をさらに最小限に抑えるには、追跡サービスを他のホストから分離します。
BizTalk Serverを実行しているコンピューターでの CPU 処理がボトルネックである場合は、追加の CPU を含めたり、高速 CPU にアップグレードしたりして、BizTalk Server実行しているコンピューターをスケールアップします。
SQL Server のガイドライン
BizTalk Serverを使用して Microsoft SQL Serverを構成する場合は、次のパフォーマンス ガイドラインを考慮してください。
可能であれば、高速なディスク サブシステムを SQL Server で使用するようにします。 バックアップ電源を備えた独立ディスク・タイプ 10 (RAID10/0+1) または記憶域ネットワーク (SAN) の冗長アレイを使用します。
BizTalk Tracking データベース (BizTalkDTADb) とは別のサーバー上の各 MessageBox データベースを分離します。 CPU リソースが使用可能な場合は、小規模な展開では、BizTalk Tracking データベースとは別の物理ディスク上の MessageBox データベースを分離するだけで十分な場合があります。
プライマリ MessageBox データベースは、CPU プロセッサの飽和またはディスク操作からの待機時間 (平均ディスク キューの長さ) が原因でボトルネックになる可能性があります。 CPU 処理がボトルネックである場合は、プライマリ MessageBox に CPU プロセッサを追加します。 そうでない場合は、マスター MessageBox データベースでの発行を無効にしてみてください。 これにより、マスター MessageBox データベースは、他の MessageBox データベースへのメッセージのルーティングをより効率的に処理できます。 発行を無効にするオプションは、複数の MessageBox データベースを使用している場合に有効です。
ディスク操作がボトルネックである場合は、BizTalk Tracking データベースを専用のSQL Server コンピューターまたは専用ディスクに移動します。 プライマリ MessageBox データベースでの CPU 処理とディスク操作がボトルネックではない場合は、同じSQL Server コンピューターに新しい MessageBox データベースを作成して、既存のハードウェアを活用できます。
「 Databases2 のファイル グループの最適化」の推奨事項に従って、MessageBox データベースと BizTalk Tracking データベースのトランザクション ログ ファイルとデータ ログ ファイルを別々の物理ディスクに分離します。
データ ファイルとログ ファイルに十分な記憶域領域を割り当てます。 それ以外の場合、SQL Serverは、ログ ファイルが保持されているディスク上のすべての使用可能な領域を自動的に使用します。 ログ ファイルの初期サイズは、シナリオの特定の要件によって異なります。 テスト結果に基づいて展開の平均ファイル サイズを見積もり、ソリューションの実装前に記憶域を拡張します。
MessageBox、Health and Activity Tracking (HAT)、Business Activity Monitoring (BAM) など、ディスク使用率の高いデータベースに十分な記憶域領域を割り当てます。 ソリューションで BizTalk Framework メッセージング プロトコルを使用する場合は、BizTalk 構成データベース (BizTalkMgmtDb) に十分な記憶域を割り当てます。
データ保持期間やシナリオで処理されるデータの量などのビジネス ニーズに応じて、BizTalk Tracking データベースが大きくなりすぎないように、HAT-Tracking データベースで "DTA Archive and Purge" SQL Server エージェント ジョブを構成します。 データベースの最大容量に達するとデータ挿入速度が制限されるため、このデータベースの増加によりパフォーマンスが低下する可能性があります。 これは、1 つの BizTalk Tracking データベースが複数の MessageBox データベースをサポートしている場合に特に当てはまります。
MessageBox データベースと BizTalk Tracking データベースをホストしているサーバーがボトルネックである場合は、スケールアップします。 CPU の追加、メモリの追加、より高速な CPU へのアップグレード、高速専用ディスクの使用によって、ハードウェアをスケールアップできます。
TempDB ファイルを複数のファイルに分割すると、I/O 操作に関連するパフォーマンスの問題が解決される可能性があります。 一般的なガイドラインとして、プロセッサごとに 1 つのファイル データ ファイルを作成し、作成されたすべてのファイルに同じサイズを使用します。
データベースの自動拡張設定を 100 から 150 MB などの固定値に変更します。 既定では、データベースの増加率は 10% に構成されているため、大規模なデータベースを増やすときに遅延が発生する可能性があります。
SQL Serverメモリは、Min Server Memory と Max Server Memory の両方を同じ値に設定することで、固定値に設定する必要があります。 一般に、物理メモリの 75% をSQL Serverに割り当て、残りのオペレーティング システムとアプリケーションに対して 25% のままにします。 これが専用のSQL Serverの場合は、オペレーティング システム用に予約されている量を少なくとも 1 GB に減らすことができます。