BizTalk Server用のログのパフォーマンス分析 (PAL) ツールを使用して、パフォーマンス カウンターを使用してレポートとグラフを生成する
PAL (ログのパフォーマンス分析) ツールは、パフォーマンス モニター カウンター ログ (既知の形式) を読み取り、複雑だが既知のしきい値 (指定) を使用して分析します。 このツールは、重要なパフォーマンス カウンターをグラフィカルにグラフ化し、しきい値を超えたときにアラートをスローする HTML ベースのレポートを生成します。 しきい値は、もともと、microsoft 製品チームによって定義されたしきい値 (BizTalk Server、Microsoft サポートのメンバーなど) に基づいています。 このツールは、従来のパフォーマンス分析に代わるものではありませんが、時間を節約するのに十分なパフォーマンス カウンター ログの分析を自動化します。 PAL ツール:
パフォーマンス カウンター ログのしきい値を分析します
大規模な Perfmon ログに役立ちます
しきい値を分析して、BizTalk Serverとオペレーティング システムのパフォーマンス カウンターのボトルネックを特定します
パフォーマンス カウンターに対して分析を実行できる拡張可能
独自のカウンターの作成に使用できます
PAL は GitHub で無料でダウンロードできます。 Microsoft ログ パーサーが必要です。 ログ パーサーは、ログ ファイル、XML ファイル、CSV ファイルなどのテキスト ベースのデータ、およびイベント ログ、レジストリ、ファイル システム、Active Directory® ディレクトリ サービスなどの Windows オペレーティング システム上の主要なデータ ソースに対する汎用クエリ アクセスを提供する、強力で汎用性の高いツールです。 このツールを使用して、大量のログ情報に対してクエリを実行できます。 ログ パーサー ツールをダウンロードできます。
異なる言語でのパフォーマンス カウンター ログでの PAL の使用
PAL ツールは、英語でのみパフォーマンス カウンター ログを分析します。 PAL ツールを他の言語のパフォーマンス カウンター ログと共に使用するには、まずログを英語に翻訳する必要があります。 Perfmon Log Translator を使用して、元のパフォーマンス カウンター ログ ファイルを英語に変換できます。
MICROSOFT BizTalk Server 2010 の PAL ツール レポートについて
PAL ツールは、Windows オペレーティング システム、Microsoft SQL Server、BizTalk Serverのしきい値の Perfmon ログ分析を提供します。 このセクションでは、PAL ツールのBizTalk Serverしきい値レポートのほとんどの分析について説明します。
注意
このトピックは長いので、PAL ツールに関する包括的な情報を簡単に参照できるように 1 か所に含めることができます。
PAL ツールでは、次の分析としきい値が報告されます。
| 分析の種類と名前 | 分析の説明 |
|---|---|
| ディスク: カーネル ダンプのディスク空き領域 | この分析では、オペレーティング システムがすべてのメモリをディスクにダンプするのに十分な空きディスク領域があることを確認します。 ディスク領域が不足している場合、オペレーティング システムは memory.dmp ファイルを作成できません。これは、カーネル ダンプの根本原因を分析するために必要なファイルです。 |
| ディスク: 論理/物理ディスク インターフェイスの分析 | この分析では、各物理ディスクのアイドル時間を調べます。 ディスクのアイドル状態が多いほど、使用されているディスクは少なくなります。 このカウンターは、論理ディスクで 1 つのディスクを使用する場合に最適です。 "% アイドル時間" は、ディスクがアイドル状態だったサンプル間隔中の時間の割合を報告します。 参考: Disk-Bound 問題の排除 |
| ディスク: 論理/物理ディスクの読み取り/書き込み待機時間の分析 | Windows がディスク パフォーマンスのボトルネックを検出する最も信頼性の高い方法は、応答時間を測定することです。 応答時間が保守的なしきい値である .025 (25 ミリ秒) を超える場合、ユーザーに影響を与える顕著な速度低下とパフォーマンスの問題が発生している可能性があります。 詳細については、このトピックの「論理/物理ディスクの読み取り/書き込み待機時間の分析」を参照してください。 |
| ディスク: 論理ディスク転送/秒 | "ディスク転送/秒" は、ディスクに対する読み取り操作と書き込み操作の速度です。 この分析のしきい値チェック、いずれかの論理ディスクで応答時間が低い (I/O 操作の応答時間が 25 ミリ秒を超える) かどうかを確認できます。 これが当てはまる場合、1 秒あたりのディスク転送は 80 以上である必要があります。 そうでない場合は、ディスク アーキテクチャを調査する必要があります。 ディスク I/O が低下する最も一般的な原因は、SAN での LUN のオーバーロードです。 詳細については、このトピックの「論理ディスク転送/秒」を参照してください。 |
| ディスク: LogicalDisk % Free Space | "% 空き領域" は、選択した論理ディスク ドライブ上で空き領域の合計に対する割合です。 使用可能なディスク ドライブ領域が 30% 未満になるまで、パフォーマンスは影響を受けません。 ディスク ドライブの 70% を使用すると、残りの空き領域はディスク ドライブの中央にあるディスクのスピンドルの近くに配置され、パフォーマンス レベルが低くなります。 空きディスク領域が不足すると、ディスクのパフォーマンスが低下する可能性があります。 |
| ディスク: IO データ操作/秒の処理と IO その他の操作の処理/秒分析 | これらのカウンターは、プロセスによって生成されたすべての I/O アクティビティをカウントして、ファイル、ネットワーク、およびデバイスの I/O を含めます。 これらの分析は、プロセスが 1 秒あたり 1,000 を超える I/O を実行している場合にチェックし、警告としてフラグを設定します。 これらの分析は、ディスク分析などの他の分析との相関関係で、I/O アクティビティに関係する可能性のあるプロセスを決定するために最適に使用されます。 |
| メモリ: 使用可能なメモリ | この分析では、使用可能なメモリの合計が低いかどうかがチェックされます。警告は使用可能な 10% で、Critical は 5% です。 また、1 時間あたり 10 MB の減少傾向が検出されると、警告がアラートされます。これは、今後のメモリ状態の可能性を示している可能性があります。 物理メモリが不足すると、特権モードの CPU とシステムの遅延が増加する可能性があります。 詳細については、このトピックの「Available MemoryAnalysis」を参照してください。 |
| メモリ: 空きシステム ページ テーブル エントリ | Free System Page Table Entries (PTE) は、システムで現在使用されていないページ テーブル エントリの数です。 この分析では、10,000 個未満の無料 PTE が存在する場合に警告が表示された無料 PTE が 5,000 個未満であるかどうかを確認することで、システムが PTE を使い切っているかどうかを判断します。 PTE が十分でないと、システム全体のハングが発生する可能性があります。 また、/3GBスイッチは無料PTEの量を大幅に減らします。 詳細については、このトピックの「Free System Page Table Entries Analysis」を参照してください。 |
| メモリ: メモリ リーク検出 | この分析では、いずれかのプロセスがシステムのメモリを大量に消費しているかどうか、およびプロセスが時間の経過と同時にメモリ消費量が増加しているかどうかを判断します。 プロセスがメモリをシステムに返す限り、メモリの大部分を消費するプロセスは問題ありません。 グラフ内の増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。 "Private Bytes" は、他のプロセスと共有できない、このプロセスが割り当てたメモリの現在のサイズ (バイト単位) です。 この分析では、1 時間あたり 10 MB、1 時間あたり 5 MB の増加傾向が確認されます。 PAL の使用可能なメモリ分析との相関関係で、この分析を使用します。 詳細については、このトピックの「メモリ リーク検出分析」を参照してください。 |
| メモリ: ハンドル リーク検出 | この分析では、すべてのプロセスを調べて、開いているハンドルの数を確認し、ハンドルリークが疑われるかどうかを判断します。 ハンドルの数が多いプロセスや、積極的な上昇傾向があるプロセスは、ハンドル リークを示す可能性があり、通常はメモリ リークが発生します。 このプロセスによって現在開かれているハンドルの合計数は、このプロセスの各スレッドによって現在開かれているハンドルの合計と同じです。 リファレンス: 診断ツールのデバッグ |
| メモリ: メモリ ページ入力/秒 | "Pages Input/sec" は、ハード ページエラーを解決するためにディスクからページを読み取る速度です。 ハード ページ フォールトが発生するのは、プロセスが参照する仮想メモリのページが、ワーキング セットまたは物理メモリのどこにもなく、ディスクから取得する必要があるときです。 この分析では、1 秒あたり 10 ページを超えるファイル読み取りがあるかどうかを確認します。 |
| メモリ: メモリ ページ/秒 | この分析では、"Pages/sec" が高い (1,000 を超える) かどうかを確認します。 高い場合は、メモリをディスクにページングしようとして、システムのメモリ不足が発生している可能性があります。 "Pages/sec" は、ハード ページエラーを解決するためにページの読み取りまたはディスクへの書き込みが行われる速度です。 このカウンターは、システム全体の遅延を引き起こす障害の種類の主要なインジケーターです。 この分析は、PAL の使用可能なメモリ分析とメモリ リーク検出分析との相関関係で使用します。 これらの分析がすべて同時にアラートをスローしている場合は、システムがメモリ不足であり、関連する疑いのあるプロセスが発生していることを示し、PAL のメモリ リーク検出分析に記載されている分析手順に従っている可能性があります。 詳細については、このトピックの「メモリ ページ/秒分析」を参照してください。 |
| メモリ: メモリ システム キャッシュ常駐バイト数 | "システム キャッシュ常駐バイト数" は、ファイル システム キャッシュ内のページング可能なオペレーティング システム コードのサイズ (バイト単位) です。 この値は、現在の物理的なページのみを含み、現在常駐していない仮想メモリ ページは含みません。 この値は、現在物理メモリ内にあるすべてのページング可能なオペレーティング システム コードを表す "Memory\\System Code Resident Bytes" のコンポーネントです。 このカウンターは、平均値ではなく、最新の監視値のみを表示します。 この分析では、1 時間あたり 10 MB の増加傾向が確認されます。 読み込み中、サーバーはディスクなどの I/O アクティビティをキャッシュするためにシステム キャッシュを使用する場合があります。 PAL のプロセス IO データ操作/秒分析と Process IO Other Operations/sec 分析との相関関係で使用します。 リファレンス: ファイル キャッシュのパフォーマンスとチューニング |
| メモリ: プールの非ページ バイト数 | "Pool Nonpaged Bytes" は、非ページ プールのサイズ (バイト単位) です。これは、ディスクに書き込むことができないオブジェクトのシステム メモリ領域ですが、割り当てられている限り物理メモリ内に残る必要があります。 この分析では、システムが最大プールの非ページ メモリ サイズに近づいているかどうかを確認します。 これは、/3 GB、物理メモリ サイズ、32 ビット/64 ビットを考慮してプール サイズを見積もり、その値が推定プール サイズの 60% を超えるかどうかを判断することによって行います。 システムが最大サイズに近づくと、システム全体のハングが発生する可能性があります。 boot.ini ファイルの /3GB スイッチ オプションを使用すると、このメモリ プールのサイズが大幅に小さくなります。 詳細については、このトピックの「プール非ページ バイト分析」を参照してください。 |
| メモリ: プール のページ バイト数 | この分析では、システムがプールのページングされた最大メモリ サイズに近づいているかどうかを確認します。 これは、/3 GB、物理メモリ サイズ、32 ビット/64 ビットを考慮してプール サイズを見積もり、その値が推定プール サイズの 60% を超えるかどうかを判断することによって行います。 システムが最大サイズに近づくと、システム全体のハングが発生する可能性があります。 boot.ini ファイルの /3GB スイッチ オプションを使用すると、このメモリ プールのサイズが大幅に小さくなります。 詳細については、このトピックの「プール ページ バイト分析」を参照してください。 |
| メモリ: プロセス スレッド数 | この分析では、すべてのプロセスがチェックされ、プロセスに 500 を超えるスレッドがあるかどうか、およびスレッドの数が 1 時間あたり 50 スレッドずつ増加しているかどうかを判断します。 スレッド数が多いプロセスや、増加傾向が強いプロセスは、通常、メモリ リークまたは高コンテキスト切り替えの原因となるスレッド リークを示している可能性があります。 高いコンテキスト切り替えにより、高い特権モードの CPU が発生します。 |
| メモリ: プロセス ワーキング セット | "ワーキング セット" は、このプロセスのワーキング セットの現在のサイズ (バイト単位) です。 ワーキング セットは、プロセス内のスレッドによって最近触れたメモリ ページのセットです。 コンピューター内の空きメモリがしきい値を超えている場合、ページは使用されていない場合でも、プロセスのワーキング セットに残ります。 空きメモリがしきい値を下回ると、ページはワーキング セットからトリミングされます。 必要に応じて、メモリを離れる前にワーキング セットにソフトフォールトメイン戻されます。 この分析では、各プロセスで 10 MB 以上の増加傾向が確認されます。 PAL の使用可能なメモリ分析との相関関係で を使用します。 リファレンス: ボトルネックの検出と排除 |
| ネットワーク: ネットワーク出力キューの長さの分析 | この分析では、ネットワーク アダプターで待機しているスレッドの数を確認します。 ネットワーク アダプターで多くのスレッドが待機している場合、ネットワーク待機時間またはネットワーク帯域幅が原因で、システムによってネットワーク I/O が飽和している可能性があります。 "出力キューの長さ" は、出力パケット キューの長さ (パケット単位) です。 これが 2 より長い場合は遅延が示され、可能であればボトルネックを見つけて排除する必要があります。 ネットワーク出力キューの一般的な原因には、多数の小さなネットワーク要求とネットワーク待機時間が含まれます。 |
| ネットワーク: ネットワーク使用率の分析 | "Bytes Total/sec" は、フレーム文字を含め、各ネットワーク アダプターで送受信されるバイト数の割合です。 "Network Interface\Bytes Received/sec" は、"Network Interface\Bytes Received/sec" と "Network Interface\Bytes Sent/sec" の合計です。 このカウンターは、ネットワーク アダプターのトラフィックが飽和しているかどうか、および別のネットワーク アダプターを追加する必要があるかどうかを確認するのに役立ちます。 問題をどの程度迅速に特定できるかは、ネットワークの種類と、他のアプリケーションと帯域幅を共有するかどうかによって異なります。 この分析では、"Bytes Total/sec" をビットに変換し、ネットワーク アダプターの現在の帯域幅と比較してネットワーク使用率を計算します。 次に、使用率が 50% を超えています。 リファレンス: .NET Core で EventCounters を使用してパフォーマンスを測定する |
| ページング ファイル: ページング ファイルの使用率と使用率のピーク率 | 使用されているページ ファイル インスタンスの量をパーセントで指定します。 「Process\\Page File Bytes」も参照してください。 この分析では、使用率が 70% を超えるかどうかを確認します。 |
| プロセッサ: プロセッサ使用率の分析とプロセス別の過剰なプロセッサ使用 | このカウンターは、プロセッサ アクティビティの主要なインジケーターであり、サンプル間隔中に観察されたビジー時間の平均パーセンテージを表示します。 これは、サービスが非アクティブな時間を監視し、その値を 100% から減算することによって計算されます。 この分析では、各プロセッサの使用率が 60% を超えるかどうかが確認されます。 その場合は、高いユーザー モードの CPU と高い特権モードのどちらであるかを判断します。 高い特権モードの CPU が疑われる場合は、PAL での特権モードの CPU 分析に関するページを参照してください。 ユーザー モード プロセッサのボトルネックが疑われる場合は、プロセス プロファイラーを使用して、CPU 使用率が高い原因となっている関数を分析することを検討してください。 |
| プロセッサ: プロセッサ キューの長さ | この分析では、平均プロセッサ キューの長さがプロセッサの数を超えているかどうかを判断します。 その場合は、プロセッサのボトルネックを示している可能性があります。 この分析は、特権モードの CPU 分析と PAL のプロセス分析による過剰なプロセッサ使用との相関関係で使用します。 詳細については、このトピックの「プロセッサ キュー長の分析」を参照してください。 |
| プロセッサ: 特権モードの CPU 分析 | このカウンターは、スレッドが特権モードで実行される時間の割合を示します。 アプリケーションがオペレーティング システム関数を呼び出すとき (ファイルまたはネットワーク I/O の実行やメモリの割り当てなど)、これらのオペレーティング システム関数は特権モードで実行されます。 この分析では、特権モードの CPU が合計 CPU の 30% を超えて消費されているかどうかを確認します。 その場合、CPU 消費量は、ネットワーク、メモリ、ディスク I/O などのプロセッサ以外の別のボトルネックによって引き起こされる可能性があります。 プロセッサとの相関関係で使用: % 割り込み時間とプロセッサ: PAL での高コンテキストスイッチング分析。 詳細については、このトピックの「特権モード CPU 分析」を参照してください。 |
| プロセッサ: 割り込み時間 | "% 割り込み時間" は、サンプル間隔中にプロセッサがハードウェア割り込みの受信とサービスに費やす時間です。 この値は、システム クロック、マウス、ディスク ドライバー、データ通信ライン、ネットワーク インターフェイス カードおよびその他の周辺機器など割り込みを発生するデバイスの処理状況を間接的に示します。 これらデバイスによるプロセッサへの割り込みは、通常タスクが完了したときまたは注意を必要とするときに発生します。 標準スレッドの実行は、割り込みの間は中断します。 システム クロックのほとんどは、割り込み処理状況のバックグラウンドを作成しながら、10 ミリ秒ごとにプロセッサに割り込みます。 このカウンターの大幅な増加は、潜在的なハードウェアの問題を示しています。 この分析では、"% 割り込み時間" が 30% を超えています。 これが発生した場合は、このアラートに関連付けられるハードウェアのデバイス ドライバーを更新することを検討してください。 リファレンス: .NET Core で EventCounters を使用してパフォーマンスを測定する |
| プロセッサ: 高コンテキスト切り替え | コンテキスト切り替えは、優先度の高いスレッドが現在実行中の優先度の低いスレッドをプリエンプションしたとき、または優先度の高いスレッドがブロックされたときに発生します。 高レベルのコンテキスト切り替えは、多くのスレッドが同じ優先度レベルを共有している場合に発生する可能性があります。 これは、多くの場合、システム上のプロセッサで競合しているスレッドが多すぎることを示します。 一般的なルールとして、プロセッサあたり 1 秒あたり 5,000 未満のコンテキスト切り替え率は心配する価値はありません。 コンテキスト切り替えレートがプロセッサあたり 1 秒あたり 15,000 を超える場合は、制約があります。 詳細については、このトピックの「高コンテキスト切り替え分析」を参照してください。 |
| Microsof BizTalk Server: BizTalk の脱水オーケストレーション | 実行時間の長いビジネス プロセスが多数同時に実行されている場合は、メモリとパフォーマンスの問題が発生する可能性があります。 オーケストレーション エンジンでは、オーケストレーション インスタンスを "退避" および "復元" することで、これらの問題に対処します。 退避とは、オーケストレーションの状態を SQL Server データベースにシリアル化するプロセスのことです。 リハイドレートは、オーケストレーションの最後の実行状態をデータベースから逆シリアル化するプロセスの逆です。 退避は、メモリ内で一度にインスタンス化する必要があるオーケストレーションの数を減らすことによって、システム リソースの使用を最小限に抑えるために使用します。 そのため、デハイドレートによってメモリ消費量は節約されますが、実行する操作は比較的コストがかかります。 この分析は、10以上の脱水をチェックします。 その場合、BizTalk Serverメモリが不足している可能性があります (仮想または物理)、多数のオーケストレーションがメッセージを待機しているか、脱水設定が正しく設定されていません。 リファレンス: オーケストレーションの脱水とリハイドレート |
| Microsoft BizTalk Server: BizTalk High Database Sessions | このカウンターには、normal (0) または exceeded (1) の 2 つの値があります。 この分析では、値 1 がチェックされます。 その場合、BizTalk は、許可されるデータベース セッションの数のしきい値を超えています。 この値は、BizTalk ホスト調整設定の "CPU あたりのデータベース接続数" の値によって制御されます。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 [BizTalk:Message Agent] パフォーマンス オブジェクト カテゴリの [Database session] パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、送信メッセージの制限だけに影響します。 詳細については、このトピックの「BizTalk High Database Sessions Analysis」を参照してください。 |
| Microsoft BizTalk Server: BizTalk のデータベース サイズが大きい | このカウンターは、データベースしきい値のメッセージ数に一覧表示されているいずれかの条件が発生した場合、値 1 に設定されます。 既定では、データベース調整しきい値のホスト メッセージ数は 50,000 の値に設定され、次の状況で調整条件がトリガーされます。 - サブスクライブしているホストの作業キュー、状態キュー、および中断キューに対してホスト インスタンスによって発行されたメッセージの合計数が 50,000 を超えています。 - スプール テーブルまたは追跡テーブル内のメッセージの数が 500,000 メッセージを超えています。 これが発生した場合は、データベース内のメッセージの数を減らす一定のアクションを検討してください。 たとえば、BizTalk ServerのSQL Server ジョブがエラーなしで実行されていることを確認し、BizTalk Server管理コンソールの [グループ ハブ] ページを使用して、多数の中断されたメッセージが原因でメッセージのビルドが発生しているかどうかを確認します。 詳細については、このトピックの「BizTalk データベース サイズの高い分析」を参照してください。 |
| Microsoft BizTalk Server: BizTalk High In-Process メッセージ数 | この分析では、高 In-Process メッセージ数カウンターを調べて、この種の調整が発生しているかどうかを判断します。 その場合は、"CPU あたりのインプロセス メッセージ数" 設定を調整することを検討してください。 このパラメーターは、送信メッセージの制限だけに影響します。 [CPU あたりのインプロセス メッセージ数] 設定に値 0 を入力して、CPU あたりのインプロセス メッセージ数に基づいて調整を無効にします。 [IN-Process messages per CPU]\(CPU あたりのインプロセス メッセージ\) 設定の既定値は 1,000 です。 この値を変更すると、メッセージの待機時間の短縮や BizTalk リソースの効率にも影響を与える可能性があることに注意してください。 詳細については、このトピックの「BizTalk High In-Process Message Count Analysis」を参照してください。 |
| Microsoft BizTalk Server: BizTalk のメッセージ配信率が高い | この分析では、メッセージ配信率が高いカウンターで値 1 がチェックされます。 メッセージ配信速度が高い場合は、処理の複雑さ、送信アダプターの速度が遅い、またはシステム リソースが一瞬不足していることが原因で発生する可能性があります。 詳細については、このトピックの「BizTalk High Message Delivery Rate Analysis」を参照してください。 |
| Microsoft BizTalk Server: BizTalk High Message Publishing Rate | BizTalk Server のメッセージ公開の制限という受信ホスト制限は、メッセージを MessageBox データベースに公開する受信アダプターまたはオーケストレーションを含むホスト インスタンスに適用されます。 この分析では、高メッセージ発行率カウンターで値 1 がチェックされます。 これが発生した場合、データベースは BizTalk MessageBox データベースへのメッセージの発行速度に追いつくことができません。 参照: - ホスト調整のパフォーマンス カウンター - BizTalk Serverでホスト調整を実装する方法 - レートベースの調整設定を変更する - ホスト調整とは |
| Microsoft BizTalk Server: BizTalk High Process Memory | BizTalk プロセス メモリ使用量調整しきい値設定は、1 ~ 100 の値が入力された場合の、プロセスのワーキング セット サイズと使用可能な仮想メモリの合計と比較して使用されるメモリの割合です。 比率が指定されている場合、プロセス メモリのしきい値は、定期的に再計算されます。 この分析では、高プロセス メモリ カウンターで値 1 がチェックされます。 詳細については、このトピックの「BizTalk High Process Memory Analysis」を参照してください。 |
| Microsoft BizTalk Server: BizTalk High System Memory | BizTalk 物理メモリ使用量調整しきい値設定は、1 から 100 までの値が入力された場合の使用可能な物理メモリの合計量と比較したメモリ消費量の割合です。 100 より大きい値を入力した場合、この設定は使用可能な物理メモリの合計量をメガバイト単位で指定することもできます。 物理メモリ使用量に基づいた制限を無効にするには、値 0 を入力してください。 既定値は 0 です。 詳細については、このトピックの「BizTalk High System Memory Analysis」を参照してください。 |
| Microsoft BizTalk Server: BizTalk のスレッド数が多い | "CPU あたりのスレッド数" は、アダプターによって使用されるスレッドを含む、ホスト プロセス内のスレッドの合計数です。 このしきい値を超えると、BizTalk Serverは EPM スレッド プールとメッセージ エージェント スレッド プールのサイズを小さくしようとします。 高負荷によって多くのスレッドを作成するシナリオでは、スレッド ベースの制限を有効にする必要があります。 このパラメーターは、受信制限と送信制限の両方に影響します。 スレッド ベースの調整は、既定では無効になっています。 詳細については、このトピックの「BizTalk のスレッド数の多い分析」を参照してください。 |
| Microsoft BizTalk Server: BizTalk ホスト キューの長さ | BizTalk ホスト キューの長さは、特定のホスト キュー内のメッセージの合計数を追跡します。 BizTalk:MessageBox:HostCounters:Host Queue – Length などの長さのサイズを使用すると、個々のホストのキューの深さを示すことによって、内部的にキューに登録されているメッセージの数をより詳細に表示できます。 このカウンターは、特定のホストがボトルネックになっているかどうかを判断するのに役立ちます。 トランスポートごとに一意のホストが使用されていると仮定すると、これは潜在的なトランスポートのボトルネックを特定するのに役立ちます。 この分析では、平均キュー長が 1 を超えているかどうかが確認されます。 ホスト キューの長さは、ターゲット ホストのすべてのキュー (Work Q、State Q、Suspended Q) のレコード数を集計することで、重み付けされたキューの長さです。 リファレンス: BizTalk Server 2010: BizTalk Server パフォーマンス テスト手法 |
| Microsoft BizTalk Server: BizTalk ホストの保留メッセージ キューの長さ | このカウンターは、特定のホストの中断されたメッセージの合計数を追跡します。 中断されたメッセージとは、システムまたはメッセージのエラーが原因で処理を停止BizTalk Serverメッセージまたはオーケストレーションのインスタンスです。 通常、システム エラーによって中断されたインスタンスは、システムの問題が解決された時点で再開可能になります。 メッセージの問題によって中断されたインスタンスは再開できないことが多く、メッセージそのものを修復して、BizTalk Server システムに再送信する必要があります。 中断されたメッセージ キューは、処理中にエラーまたはエラーが発生した作業項目を含むキューです。 保留キューのメッセージは最終的に、修正されて再処理されるか、削除されます。 この分析では、中断されたメッセージの発生を確認します。 増加傾向は、重大な処理エラーを示している可能性があります。 参照: - BizTalk Serverの正常性とパフォーマンスの監視 - Microsoft BizTalk Serverのトラブルシューティング |
| BizTalk Server: BizTalk アイドル オーケストレーション | ホスト インスタンスが現在ホストしている、アイドル状態のオーケストレーション インスタンスの数。 このカウンターは、進行していないが脱水不可能なオーケストレーションを指します。 この状況は、オーケストレーションがブロックされ、アトミック トランザクションで受信、リッスン、または遅延を待機しているときに発生する可能性があります。 脱水不可能なオーケストレーションが多数蓄積されると、BizTalk のメモリ不足が発生する可能性があります。 退避とは、オーケストレーションの状態を SQL Server データベースにシリアル化するプロセスのことです。 リハイドレートは、このプロセスの逆です。オーケストレーションの最後の実行状態をデータベースから逆シリアル化します。 退避は、メモリ内で一度にインスタンス化する必要があるオーケストレーションの数を減らすことによって、システム リソースの使用を最小限に抑えるために使用します。 エンジンは、状態を保存することでインスタンスを退避し、インスタンスに必要なメモリを解放します。 休止しているオーケストレーション インスタンスを退避することにより、多数の長時間実行されるビジネス プロセスを単一のコンピューターで同時に実行できるようになります。 この分析では、1 時間あたり 1 つのアイドル オーケストレーションの増加傾向が確認されます。 リファレンス: オーケストレーションの脱水とリハイドレート。 |
| BizTalk Server: BizTalk 受信待機時間 | メッセージング エンジンがアダプターからドキュメントを受信してから MessageBox に発行されるまでの平均待機時間 (ミリ秒)。 BizTalk の一部のユーザーは待機時間を短縮することが重要であるため、受信アダプターにドキュメントが費やした時間を追跡することが重要です。 詳細については、このトピックの「BizTalk 受信待機時間分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ配信の遅延 | これは、各メッセージ配信バッチに課される現在の遅延 (ミリ秒単位) です (メッセージ配信が調整されている場合に適用されます)。 調整に関しては、メッセージが受信か送信かに応じて、メッセージの発行または処理に遅延が適用されます。 遅延期間は、調整条件の重大度に比例します。 重大度調整条件が高いほど、重大度調整条件よりも長い調整期間が開始されます。 この遅延期間は、条件が変わるたびに制限のメカニズムによって特定の範囲内で期間が調整されます。 現在の遅延期間は、メッセージ配信遅延 (ms) と、BizTalk:Message Agent パフォーマンス オブジェクト カテゴリに関連付けられているメッセージ発行遅延 (ms) パフォーマンス カウンターによって公開されます。 この分析では、5 秒を超えるメッセージ配信遅延が確認されます。 メッセージ配信の遅延が長いと、負荷が高いために調整が重くなる可能性があります。 リファレンス: BizTalk Serverホスト調整を実装する方法。 |
| BizTalk Server: BizTalk メッセージ配信の調整状態 | BizTalk メッセージ配信の調整状態は、調整の主要なインジケーターの 1 つです。 これは、システムがメッセージ配信を調整しているかどうかを示すフラグです (XLANG メッセージ処理と送信トランスポートに影響を与える)。 調整条件は、カウンターの数値によって示されます。 詳細については、このトピックの「BizTalk メッセージ配信調整状態分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ発行の遅延 | メッセージの発行を調整するために、対象となる各バッチに挿入される遅延。 調整に関しては、メッセージが受信か送信かに応じて、メッセージの発行または処理に遅延が適用されます。 遅延期間は、調整条件の重大度に比例します。 重大度調整条件が高いほど、重大度調整条件よりも長い調整期間が開始されます。 この遅延期間は、条件が変わるたびに制限のメカニズムによって特定の範囲内で期間が調整されます。 現在の遅延期間は、BizTalk:Message Agent パフォーマンス オブジェクト カテゴリに関連付けられているメッセージ配信遅延 (ms) とメッセージ発行遅延 (ms) パフォーマンス カウンターを通じて公開されます。 この分析では、5 秒を超えるメッセージ発行遅延がチェックされます。 メッセージ配信の遅延が長い場合は、負荷が高いために調整が重くなる可能性があります。 リファレンス: BizTalk Serverでホスト調整を実装する方法。 |
| BizTalk Server: BizTalk MessageBox データベース接続エラー | このパフォーマンス カウンターは、ホスト インスタンスの起動後に失敗した試行データベース接続の数です。 BizTalk データベースをホストしているSQL Server サービスが何らかの理由で使用できなくなった場合、データベース クラスターはアクティブ なコンピューターからパッシブ コンピューターにリソースを転送します。 このフェールオーバー処理中に BizTalk Server サービスのインスタンスがデータベース接続の障害を検出すると、自動的にデータベースの再接続が実行されます。 正常に動作しているデータベース コンピューター (先ほどまでパッシブ側であったコンピューター) が、フェールオーバーでリソースを引き継いだ後、データベース接続の処理を開始します。 詳細については、このトピックの「BizTalk MessageBox データベース接続エラー分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージングの待機時間: 要求応答の待機時間 | アダプターからメッセージング エンジンへと渡された要求が、応答ドキュメントとしてアダプターに返されるまでの平均待機時間 (ミリ秒)。 このトピックの BizTalk 受信待機時間分析での待機時間の測定方法を示すグラフを参照してください。 待機時間が短い環境であると仮定すると、この分析では、Request-Response 待機時間が 5 秒を超えるかどうかが確認されます。 これは、受信アダプターと送信アダプターの間の処理遅延を示している可能性があります。 参照: - 要求/応答メッセージング - ソリューションのスケーリング |
| BizTalk Server: BizTalk メッセージング発行の調整状態 | BizTalk メッセージ発行の調整状態は、調整の主要なインジケーターの 1 つです。 これは、システムがメッセージの発行を調整しているかどうかを示すフラグです (XLANG メッセージ処理と受信トランスポートに影響を与えます)。 詳細については、このトピックの「BizTalk メッセージング発行調整状態分析」を参照してください。 |
| BizTalk Server: BizTalk オーケストレーションの中断/秒 | 中断されたメッセージとは、システムまたはメッセージのエラーが原因で処理を停止BizTalk Serverメッセージまたはオーケストレーションのインスタンスです。 通常、システム エラーによって中断されたインスタンスは、システムの問題が解決された時点で再開可能になります。 メッセージの問題によって中断されたインスタンスは再開できないことが多く、メッセージそのものを修復して、BizTalk Server システムに再送信する必要があります。 この分析では、中断されたメッセージ/オーケストレーションがチェックされます。 参照: - BizTalk Serverの正常性とパフォーマンスの監視 - Microsoft BizTalk Serverのトラブルシューティング |
| BizTalk Server: BizTalk オーケストレーションの完了/秒 | これは、1 秒あたりに完了した BizTalk オーケストレーションの数です。 これは、BizTalk が処理しているスループットの程度を示す適切なインジケーターです。 この分析では、統計のみが提供されます。 リファレンス: ソリューションのスケーリング |
| BizTalk Server: BizTalk オーケストレーションが破棄されました | ホスト インスタンスの起動以降にメモリから破棄されたオーケストレーション インスタンスの数。 エンジンがオーケストレーション状態の永続化に失敗した場合、そのオーケストレーションは破棄可能と見なされます。 この分析では、破棄されたメッセージがチェックされます。 リファレンス: BizTalk Core エンジンの WebLog |
| BizTalk Server: メモリに常駐する BizTalk オーケストレーション | ホスト インスタンスによって現在ホストされているオーケストレーション インスタンスの数。 この分析では、メモリ内に存在するオーケストレーションの増加傾向と、メモリ内に存在するオーケストレーションの 50% を超えるオーケストレーションが脱水不可能かどうかを確認します。 詳細については、「メモリ分析に常駐する BizTalk オーケストレーション」を参照してください。 |
| BizTalk Server: BizTalk 送信アダプターの待機時間 | これは、アダプターがメッセージング エンジンからドキュメントを取得してからアダプターから送信されるまでの平均待機時間 (秒) です。 このトピックの BizTalk 受信待機時間分析での待機時間の測定方法を示すグラフを参照してください。 待機時間が短い環境であると仮定すると、この分析では、平均で 5 秒を超える送信アダプターの待機時間がチェックされます。 これは、このホスト インスタンスの送信アダプターを介したメッセージの転送の処理遅延を示している可能性があります。 このホスト インスタンスに複数の送信アダプターが存在する場合は、それらを独自のホストに分割して、待機時間が長い送信アダプターを決定することを検討してください。 参照: - 要求/応答メッセージング。 - BizTalk Server 2006: BizTalk Server 2006 での SOAP アダプターの使用に関するスケーラビリティのケース スタディ - BizTalk レベルでのボトルネックの特定 - BizTalk Serverの低待機時間シナリオの最適化 |
| BizTalk Server: BizTalk 保留中のメッセージ | MessageBox への受信として確認されていない受信メッセージの数。 保留中のメッセージは、メモリにプルされ、XLANG オーケストレーションに配信されたが、まだ処理されていないメッセージです。 この状況は、データ損失とは関係ありません。 オーケストレーションへのメッセージの配信は複数ステップのプロセスであり、単にデータベースのスプール テーブルに存在するメッセージのインスタンスです。 これらの保留中のメッセージは、インプロセス メッセージとしてカウントされます。そのため、多数のメモリをメモリに格納すると、システムでメモリ調整が発生する可能性があります。 [内部メッセージ キュー サイズ] 設定を調整すると、保留中のメッセージの数を制御するのに役立つ場合があります。 [cpu ごとのメッセージ数の In-Process] 設定は、保留中のメッセージが多数発生したときに調整が呼び出されるタイミングに影響します。 これらの設定は、BizTalk 管理コンソールの [ホスト] プロパティにあります。 この分析チェックでは、このカウンターの統計のみが表示されます。 リファレンス: オーケストレーション エンジンのパフォーマンス カウンター。 |
| BizTalk Server: BizTalk 永続化ポイント/秒 | 永続化されたオーケストレーション インスタンスの 1 秒あたりの平均数。 オーケストレーション エンジンは、さまざまな場所で実行しているオーケストレーション インスタンスの状態を保存します。 オーケストレーション インスタンスのリハイドレート、制御されたシャットダウンからの起動、または予期しないシャットダウンからの復旧が必要な場合は、最後の永続化ポイントからオーケストレーション インスタンスが実行されます。 オーケストレーション インスタンスを保持するには、オーケストレーションが直接または間接的に参照するすべてのオブジェクト インスタンスを (他のオブジェクトを通じて) シリアル化できる必要があります。 メッセージ永続化の頻度 (データを永続化する必要がある回数) が増えると、全体的なパフォーマンスが低下します。 実際には、各永続化ポイントはデータベースへのラウンド トリップであるため、永続化ポイントを回避または統合することで、可能な限り永続化ポイントの頻度を減らします。 永続化ポイントが発生するタイミングの詳細については、以下のリファレンスを参照してください。 この分析では、平均して 1 秒あたり 10 個を超える永続化ポイントがチェックされます。 これは一般的な出発点です。 参照: - オーケストレーションでの永続化 - 永続化とオーケストレーション エンジン |
| BizTalk Server: BizTalk プライベート バイト | これは、ホスト インスタンスに割り当てられたプライベート メモリのメガバイトであり、"\Process(*)\Private Bytes" パフォーマンス カウンターに相当します。 この分析では、いずれかのホスト インスタンスがシステムのメモリの大きなサイズを消費しているかどうか、およびホスト インスタンスが時間の経過と共にメモリ消費量が増加しているかどうかを判断します。 詳細については、このトピックの「BizTalk プライベート バイト分析」を参照してください。 |
| BizTalk Server: BizTalk スプール テーブルのサイズ | MessageBox スプール テーブルには、システム内の各メッセージのレコードが含まれます (アクティブまたは "ガベージ コレクション" を待機しています)。 このテーブル内の行数と 1 秒あたりの受信メッセージ数を監視しながら、システム負荷を増やすことで、持続可能な最大スループットを簡単に見つけることができます。 単に、1) スプール テーブルが無期限に増加し始めるか、2) 1 秒あたりの受信メッセージ数 (どちらか早い方) まで入力負荷を増やします。これが最大の持続可能なスループットです。 要約すると、他のインジケーターに関係なく、このメジャーを使用すると、システムがオーバードライブされているかどうかを迅速かつ簡単に評価できます。 BizTalk スプール テーブルのサイズが増加傾向にある場合、メッセージ配信速度の不均衡 (入力レートが出力レートを超える) またはデータベース サイズによる調整による調整が発生する可能性があります。 この分析では、BizTalk スプール テーブル サイズの増加傾向を確認します。 参照: - BizTalk Server 2004 SP1 のスループットと容量について - 持続可能なロード テスト - エンジンのパフォーマンスをテストするときの推奨事項。 |
| BizTalk Server: BizTalk 追跡データ サイズ | BizTalk Serverシステムで処理されるデータが増えるにつれて、BizTalk Tracking データベース (BizTalkDTADb) のサイズは拡大し続けています。 サイズが増加してもチェックされないので、システム パフォーマンスが低下し、TDDS (Tracking Data Delivery Service) でエラーが発生することがあります。 一般的な追跡データに加えて、追跡メッセージもメッセージ ボックス データベースに累積されます。これにより、ディスクのパフォーマンスが低下します。 この分析では、追跡データ サイズで 1 時間あたり 5 MB を超える増加傾向が確認されます。 リファレンス: BizTalk 追跡データベースのアーカイブおよび削除 |
| BizTalk Server: BizTalk トランザクション スコープが中止されました | これは、ホスト インスタンスの開始後に中止された実行時間の長いスコープまたはアトミック スコープの数です。 トランザクション スコープの中止は、オーケストレーション内のトランザクション スコープで発生するエラーです。 スコープの補正ハンドラーは、スコープが正常に完了した場合にのみ呼び出されますが、周囲のスコープが中止することを決定したため (プロセスの後半で発生する可能性があるエラーが原因で) 元に戻す必要があることを理解しておくことが重要です。 また、トランザクションが中止された場合、状態の "自動" ロールバックは発生しません。 この結果は、例外ハンドラーと補正ハンドラーを使用してプログラムで実現できます。 通常、トランザクション スコープの中止は運用環境では発生しません。したがって、この分析では、中止されたトランザクション スコープの発生を確認します。 リファレンス: トランザクション |
| BizTalk Server: BizTalk トランザクション スコープ補正 | 補正は、エラー状態に応じて正常にコミットされた作業の論理的な元に戻すと考えることができます。 スコープの補正ハンドラーは、スコープが正常に完了した場合にのみ呼び出されますが、周囲のスコープが中止することを決定したため (プロセスの後半で発生する可能性があるエラーが原因で) 元に戻す必要があることを理解しておくことが重要です。 また、トランザクションが中止された場合、状態の "自動" ロールバックは発生しません。 これは、例外処理および補正処理を使ったプログラムによって実現できます。 通常、トランザクション スコープの補正は運用環境では発生しません。したがって、この分析では、中止されたトランザクション スコープの発生を確認します。 リファレンス: トランザクション |
| BizTalk Server: BizTalk 仮想バイト数 | これは、ホスト インスタンスの仮想メモリ用に予約されたメガバイトです。 この分析では、いずれかのホスト インスタンスがシステムのメモリを大量に消費しているかどうか、およびホスト インスタンスが時間の経過と同時にメモリ消費量を増やしているかどうかを判断します。 詳細については、このトピックの「BizTalk 仮想バイト分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェント データベース セッション調整 | これは、それぞれの BizTalk 調整設定と比較して、MessageBox に対する開いているデータベース接続の数です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 詳細については、このトピックの「BizTalk メッセージ エージェント データベース セッション調整分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェント データベース セッション調整しきい値 | これは、MessageBox に対する開いているデータベース接続の数の現在のしきい値です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 詳細については、このトピックの「BizTalk メッセージ エージェント データベース セッション調整しきい値分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェントのインプロセス メッセージ数の調整 | これは、サービス クラスが処理している同時メッセージの数です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 詳細については、このトピックの「BizTalk メッセージ エージェントのインプロセス メッセージ数調整分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェントのインプロセス メッセージ数調整しきい値 | これは、サービス クラスが処理している同時メッセージの数の現在のしきい値です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 詳細については、このトピックの「BizTalk メッセージ エージェントのインプロセス メッセージ数調整しきい値分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェント プロセス メモリ使用量 (MB) 調整 | これは、現在のプロセス (MB) のメモリ使用量です。 BizTalk プロセス のメモリ調整は、発行するバッチにメモリ要件が急激である場合、またはメッセージを処理しているスレッドが多すぎる場合に発生する可能性があります。 詳細については、このトピックの「BizTalk メッセージ エージェント プロセス メモリ使用量 (MB) 調整分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェント プロセス メモリ使用量 (MB) 調整しきい値 | これは、現在のプロセス (MB) のメモリ使用量の現在のしきい値です。 しきい値は、このプロセスで使用できる実際のメモリ量とそのメモリ消費パターンに応じて動的に調整される場合があります。 BizTalk プロセス のメモリ調整は、発行するバッチにメモリ要件が急激である場合、またはメッセージを処理しているスレッドが多すぎる場合に発生する可能性があります。 詳細については、このトピックの「BizTalk メッセージ エージェント プロセス メモリ使用量 (MB) 調整しきい値分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェントのスレッド数の調整 | BizTalk プロセス内のスレッドの合計数。 "CPU あたりのスレッド数" は、アダプターによって使用されるスレッドを含む、ホスト プロセス内のスレッドの合計数です。 このしきい値を超えると、BizTalk Server は、EPM スレッド プールのサイズとメッセージ エージェント スレッド プールを減らそうとします。 高負荷によって多くのスレッドを作成するシナリオでは、スレッド ベースの制限を有効にする必要があります。 このパラメーターは、受信制限と送信制限の両方に影響します。 スレッド ベースの調整は、既定では無効になっています。 この分析では、BizTalk スレッド数が調整のしきい値の 80% を超えているかどうかを調べ、調整条件が発生する可能性を示します。 参照: - ホスト調整のパフォーマンス カウンター - BizTalk Serverでホスト調整を実装する方法 - 既定のホスト調整設定を変更する方法 - アダプターのパフォーマンスに影響する構成パラメーター - スレッド、DB セッション、調整 |
| BizTalk Server: BizTalk メッセージ エージェントのスレッド数調整しきい値 | これは、プロセス内のスレッドの合計数の現在のしきい値です。 "CPU あたりのスレッド数" は、アダプターによって使用されるスレッドを含む、ホスト プロセス内のスレッドの合計数です。 このしきい値を超えると、BizTalk Server は、EPM スレッド プールのサイズとメッセージ エージェント スレッド プールを減らそうとします。 負荷が高い場合に多数のスレッドが作成される可能性があるシナリオでは、スレッドベースの調整を有効にする必要があります。 このパラメーターは、受信制限と送信制限の両方に影響します。 この分析では、この調整設定が既定値以外に設定されているかどうかを確認します。 スレッド ベースの調整は、既定では無効になっています。 参照: - ホスト調整のパフォーマンス カウンター - BizTalk Serverでホスト調整を実装する方法 - 既定のホスト調整設定を変更する方法 - アダプターのパフォーマンスに影響する構成パラメーター - スレッド、DB セッション、調整 |
論理/物理ディスクの読み取り/書き込み待機時間の分析
Windows がディスク パフォーマンスのボトルネックを検出する最も信頼性の高い方法は、応答時間を測定することです。 応答時間が保守的なしきい値である .025 (25 ミリ秒) を超える場合、ユーザーに影響を与える顕著な速度低下とパフォーマンスの問題が発生している可能性があります。
ディスク待機時間の低下の一般的な原因は、ディスクの断片化、パフォーマンス キャッシュ、飽和状態の SAN の超過、ディスクの負荷が多すぎることです。 SPA ツールを使用して、ディスクを使用して上位のファイルとプロセスを特定します。 また、"Process IO Data Operations/sec" と "Process IO Other Operations/sec" をチェックして、最も多くのディスク I/O を消費しているプロセスを確認します。 パフォーマンス モニター カウンターでは、関連するファイルを指定できないことに注意してください。
リファレンス
論理ディスク転送/秒
"ディスク転送/秒" は、ディスクに対する読み取り操作と書き込み操作の速度です。 ディスク転送はディスク I/O と直接の相関関係ではありませんが、発生しているディスク操作の数が示されます。 シーケンシャル I/O とランダム I/O を平均すると、一般的な経験則として 1 秒あたり約 80 個の I/O が生成されます。 そのため、SAN ドライブでは、負荷がかかっているときに 1 秒あたり 80 を超える I/O を実行することが想定されます。 この分析のしきい値チェック、いずれかの論理ディスクで応答時間が低い (I/O 操作の応答時間が 25 ミリ秒を超える) かどうかを確認できます。 これが当てはまる場合は、1 秒あたりのディスク転送が 80 以上になると予想されます。 そうでない場合は、ディスク アーキテクチャを調査する必要があります。 ディスク I/O の低下の最も一般的な原因は、SAN での論理ユニット番号 (LUN) のオーバーロードです。つまり、複数の LUN が小さな物理ディスク アレイを使用している状態を意味します。
使用可能なメモリ分析
"Available Mbytes" は、コンピューター上で実行されているプロセスで使用できる物理メモリの量 (MB 単位) です。 仮想メモリ マネージャーは、オペレーティング システムとプロセスで使用可能な最小バイト数を維持するために、物理メモリとディスクで使用される領域を継続的に調整します。 使用可能なバイト数が多い場合、Virtual Memory Manager を使用すると、プロセスのワーキング セットを拡張したり、新しいページが追加されるたびに古いページを削除して安定した状態を維持したりできます。 使用可能なバイト数が少ない場合、仮想メモリ マネージャーは、必要最小限のプロセスを維持するために、作業セットをトリミングする必要があります。
この分析では、使用可能なメモリの合計が低いかどうかを確認します。警告は使用可能な 10%、クリティカルは 5% です。 また、1 時間あたり 10 MB の減少傾向が検出されると、今後のメモリ状態の可能性を示す警告も通知されます。 物理メモリが不足すると、特権モードの CPU とシステムの遅延が増加する可能性があります。
リファレンス
メモリ リーク検出の分析
この分析では、いずれかのプロセスがシステムのメモリを大量に消費しているかどうか、およびプロセスが時間の経過に伴ってメモリ消費量が増加しているかどうかを判断します。 プロセスがメモリをシステムに返す限り、メモリの大部分を消費するプロセスは問題ありません。 グラフで増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。 プライベート バイトは、他のプロセスと共有できない、このプロセスが割り当てたメモリの現在のサイズ (バイト単位) です。 この分析では、1 時間あたり 10 MB、1 時間あたり 5 MB の増加傾向を確認します。 この分析は、使用可能なメモリ分析との相関関係で使用します。
また、新しく開始されたプロセスは、単純に通常のスタートアップ動作である場合、最初はメモリ リークとして表示されることに注意してください。 メモリ リークは、プロセスがメモリを消費し続け、長時間にわたってメモリを解放しない場合に発生します。
メモリ リーク状態が疑われる場合は、Debug Diag ツールをインストールして使用します。 Debug Diag Tool の詳細については、「リファレンス」セクションを参照してください。
リファレンス
メモリ ページ/秒の分析
この分析では、"Pages/sec" が高いかどうかを確認します。 高い場合は、メモリをディスクにページングしようとして、システムでメモリが不足している可能性があります。 "Pages/sec" は、ハード ページエラーを解決するためにページがディスクから読み取られたりディスクに書き込まれたりする速度です。 このカウンターは、システム全体の遅延を引き起こすフォールトのプライマリ インジケーターです。 これは、"Memory\Pages Input/sec" と "Memory\Pages Output/sec" の合計です。 ページ数でカウントされるため、"Memory\Page Faults/sec" などの他のページ数と比較できます。
このカウンターは常に 1,000 を下回る必要があります。 この分析では、1,000 を超す値がチェックされます。 この分析は、使用可能なメモリ分析とメモリ リーク検出分析との相関関係で使用します。 すべての分析が同時にアラートをスローしている場合は、システムがメモリ不足であることを示している可能性があります。 このトピックの「メモリ リーク検出の分析に関する追加情報」に記載されている分析手順に従います。
リファレンス
メモリ システム キャッシュ常駐バイト分析
"システム キャッシュ常駐バイト数" は、ファイル システム キャッシュ内のページング可能なオペレーティング システム コードのサイズ (バイト単位) です。 この値は、現在の物理的なページのみを含み、現在常駐していない仮想メモリ ページは含みません。 タスク マネージャーに表示されるシステム キャッシュの値と同じです。 その結果、この値は、ファイル システム キャッシュで使用されている仮想メモリの実際の量よりも小さくなる可能性があります。 この値は、現在物理メモリ内にあるすべてのページング可能なオペレーティング システム コードを表す "Memory\\System Code Resident Bytes" のコンポーネントです。 このカウンターは、平均値ではなく、最新の監視値のみを表示します。
この分析では、1 時間あたり 10 MB の増加傾向が確認されます。 読み込み中、サーバーはディスクなどの I/O アクティビティをキャッシュするためにシステム キャッシュを使用する場合があります。 Process IO Data Operations/sec および Process IO Other Operations/sec 分析との相関関係で使用します。
プロセス別のプロセッサ使用率分析と過剰なプロセッサ使用
"% Processor Time" は、プロセッサが非アイドル スレッドの実行に費やした経過時間の割合です。 これは、アイドル状態のスレッドがサンプル間隔でアクティブになっている期間を測定し、その時間を間隔期間から減算することによって計算されます。 (各プロセッサには、他のスレッドを実行する準備ができていないときにサイクルを消費するアイドル スレッドがあります)。このカウンターは、プロセッサ アクティビティの主要なインジケーターであり、サンプル間隔中に観察されたビジー時間の平均パーセンテージを表示します。 これは、サービスが非アクティブな時間を監視し、その値を 100% から減算することによって計算されます。
この分析では、個々のプロセッサの使用率が 60% を超えるかどうかが確認されます。 その場合は、高いユーザー モードの CPU と高い特権モードのどちらであるかを判断します。 高い特権モードの CPU が疑われる場合は、「特権モードの CPU 分析」を参照してください。 ユーザー モード プロセッサのボトルネックが疑われる場合は、プロセス プロファイラーを使用して、CPU 使用率が高い原因となっている関数を分析することを検討してください。 詳細については、「How To: Identify Functions causing a High User-mode CPU ボトルネック for Server Applications in a Production Environment」を参照してください。
プロセッサ キューの長さの分析
"プロセッサ キューの長さ" は、プロセッサ キュー内のスレッドの数です。 ディスク カウンターとは異なり、このカウンターは実行準備ができているスレッドのみを表示し、実行中のスレッドは表示しません。 プロセッサが複数ある場合でもプロセッサ時間のキューは 1つです。 そのため、コンピューターにプロセッサが複数ある場合は、この値を負荷を処理しているプロセッサの数で割る必要があります。 プロセッサごとの、持続されているプロセッサのキューが 10 スレッドに満たない場合は、負荷にもよりますが通常有効です。
この分析では、平均プロセッサ キューの長さがプロセッサの数を超えているかどうかを判断します。 その場合は、プロセッサのボトルネックを示している可能性があります。 この分析は、特権モードの CPU 分析とプロセス別の過剰なプロセッサ使用との相関関係で使用します。 プロセッサ キューは、別のアクティブなスレッドが現在実行されているため、準備はできてもプロセッサで実行できないスレッドのコレクションです。 プロセッサの数よりも多くのスレッドの持続的または定期的なキューは、プロセッサのボトルネックを示す良い兆候です。
このカウンターを "Processor\% Processor Time" カウンターと組み合わせて使用して、アプリケーションがより多くの CPU を利用できるかどうかを判断できます。 マルチプロセッサ コンピューターでも、プロセッサ時間のキューは 1 つあります。 したがって、マルチプロセッサ コンピューターでは、"プロセッサ キューの長さ" (PQL) の値を、ワークロードにサービスを提供するプロセッサの数で除算します
CPU が非常にビジー状態 (90% 以上の使用率) で、PQL 平均がプロセッサの数よりも一貫して高い場合は、追加の CPU の恩恵を受ける可能性のあるプロセッサのボトルネックが発生する可能性があります。 または、アプリケーション レベルでスレッドとキューの数を減らすことができます。 これにより、コンテキストの切り替えが少なくなります。これは、CPU 負荷を軽減するために適しています。 CPU 使用率が低い高い PQL の一般的な理由は、プロセッサ時間の要求がランダムに到着し、スレッドがプロセッサに不規則な時間を要求することです。 これは、プロセッサがボトルネックではないことを意味します。 代わりに、改善する必要があるスレッドロジック。
ユーザー モード プロセッサのボトルネックが疑われる場合は、プロセス プロファイラーを使用して、CPU 使用率が高い原因となっている関数を分析することを検討してください。 詳細については、「How To: Identify Functions causing a High User-mode CPU ボトルネック for Server Applications in a Production Environment」の記事を参照してください。
特権モードの CPU 分析
このカウンターは、スレッドが特権モードで実行される時間の割合を示します。 アプリケーションがオペレーティング システム関数を呼び出すとき (ファイルまたはネットワーク I/O の実行やメモリの割り当てなど)、これらのオペレーティング システム関数は特権モードで実行されます。
高い特権モードの CPU は、コンピューターがシステム I/O と実際 (ユーザー モード) の作業に多くの時間を費やしていることを示します。 "% Privileged Time" は、プロセス スレッドが特権モードでコードの実行に費やした経過時間の割合です。 Windows システム サービスが呼び出されると、多くの場合、サービスは特権モードで実行され、システムプライベート データにアクセスできるようになります。 このようなデータは、ユーザー モードで実行されているスレッドによるアクセスから保護されます。 システムの呼び出しは明示的に、またはページ フォールトや割り込みのように暗示的に行われる場合があります。 一部の初期のオペレーティング システムとは異なり、Windows では、ユーザーモードと特権モードの従来の保護に加えて、サブシステム保護にプロセス境界が使用されます。 アプリケーションに代わって Windows によって実行される作業の一部は、プロセスの特権時間に加えて、他のサブシステム プロセスに表示される場合があります。
この分析では、特権モードの CPU が合計 CPU の 30% を超えて消費されているかどうかを確認します。 その場合、CPU 消費量は、ネットワーク、メモリ、ディスク I/O などのプロセッサ以外の別のボトルネックによって引き起こされる可能性があります。 % 割り込み時間と高コンテキスト切り替え分析との相関関係で使用します。
高コンテキスト切り替え分析
コンテキスト切り替えは、優先度の高いスレッドが現在実行中の優先度の低いスレッドをプリエンプションしたとき、または優先度の高いスレッドがブロックされたときに発生します。 高レベルのコンテキスト切り替えは、多くのスレッドが同じ優先度レベルを共有している場合に発生する可能性があります。 これは、多くの場合、システム上のプロセッサで競合しているスレッドが多すぎることを示します。 プロセッサ使用率があまり表示されず、コンテキスト切り替えのレベルが非常に低い場合は、スレッドがブロックされていることを示している可能性があります。
高コンテキストの切り替えは、特権モードの CPU と全体的な CPU が高い場合にのみ調査する必要があります。 一般的なルールとして、プロセッサあたり 1 秒あたり 5,000 未満のコンテキスト切り替え率は心配する価値はありません。 コンテキスト切り替えレートがプロセッサあたり 1 秒あたり 15,000 を超える場合は、制約があります。
この分析では、高い CPU、高い特権モードの CPU、および高 (プロセッサあたり 5,000 を超える) システム コンテキスト スイッチがすべて同時に発生しているかどうかを確認します。 高コンテキストの切り替えが発生している場合は、システムで実行されているスレッドとプロセスの数を減らします。
BizTalk ハイ データベース セッション分析
このカウンターには、通常 (0) または超えた (1) という 2 つの値があります。 この分析では、値 1 がチェックされます。 その場合、BizTalk は、許可されるデータベース セッションの数のしきい値を超えています。 この値は、BizTalk ホスト調整設定の "CPU あたりのデータベース接続数" の値によって制御されます。
"CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 ホストごとの一般的なセッション プールのアイドル状態のデータベース セッションは、この数に含まれません。また、この確認処理は、ホスト インスタンスによって実際に使用されるセッションの数に厳密に基づいて実行されます。 このオプションは、既定では無効になっています。通常、この設定は、データベース サーバーがボトルネックである場合、またはBizTalk Server システム内のローエンド データベース サーバーの場合にのみ有効にする必要があります。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのデータベース セッション パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、送信メッセージの制限だけに影響します。 データベース セッションの数に基づいた制限を無効にするには、値 0 を入力してください。 既定値は 0 です。
注意
"MaxWorkerThreads" レジストリ キーは、BizTalk で使用できる数のスレッドに影響を与え、ほとんどの BizTalk スレッドがデータベース接続ビジー状態の場合に役立ちます。
リファレンス
BizTalk のデータベース サイズの高い分析
このカウンターは、このプロセスが発行したデータベース キュー内のメッセージの数を参照します。 この値は、すべてのホストのキュー テーブル内の項目数およびスプールと追跡テーブル内の項目数によって測定されます。 キューには、作業キュー、状態キュー、および中断キューが含まれます。 プロセスが複数のキューに公開している場合、このカウンターには、すべてのキューの加重平均が反映されます。
ホストが再起動すると、メモリに格納されていた統計は失われます。 オーバーヘッドが発生するため、BizTalk Serverは、少なくとも 100 個の発行がある場合にのみ統計の収集を再開し、再起動されたホスト プロセス内の発行総数の 5% が発生します。
このカウンターは、データベースしきい値のメッセージ数に一覧表示されているいずれかの条件が発生した場合、値 1 に設定されます。 このしきい値については、以下の「既定のホスト調整設定を変更する方法」を参照してください。 既定では、データベース調整しきい値のホスト メッセージ数は 50,000 の値に設定されています。これにより、次の状況で調整条件がトリガーされます。
サブスクライブを行うホストの作業キュー、状態キュー、および保留キューに対しこのホスト インスタンスによって公開されるメッセージの総数が、50,000 を超えた場合
スプール テーブルまたは追跡テーブル内のメッセージの数が 50,000 を超えた場合
中断されたメッセージはデータベース計算のメッセージ数に含まれるため、BizTalk サーバーで負荷が低い場合や負荷が発生していない場合でも、メッセージ発行の調整が発生する可能性があります。
この分析では、値 1 がチェックされます。 これが発生した場合は、データベース内のメッセージの数を減らす一連のアクションを検討してください。 たとえば、BizTalk SQL Server ジョブがエラーなしで実行されていることを確認し、BizTalk 管理コンソールのグループ ハブを使用して、多数の中断されたメッセージが原因でメッセージのビルドが発生しているかどうかを確認します。
リファレンス
BizTalk High In-Process メッセージ数の分析
[ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 この番号には、データベースから取得されたメッセージは含まれませんが、メモリ内キューでの配信を待機しています。 インプロセス メッセージの数を監視するには、BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのインプロセス メッセージ数パフォーマンス カウンターを使用します。 このパラメーターは、調整条件を考慮する際の調整メカニズムにヒントを提供します。 実際のしきい値は、自律的に調整されます。 実際のしきい値を確認するには、インプロセス メッセージ数のパフォーマンス カウンターを監視します。
このパラメーターは、メッセージの平均サイズが大きい、またはメッセージの処理に多数のメッセージが必要な場合がある、大きなメッセージ シナリオでは、小さい値に設定できます。 これは、シナリオでメモリベースの調整が頻繁に発生し、メモリしきい値が大幅に低い値に自動的に調整される場合に明らかになります。 このような結果は、過度のメモリ消費を避けるため、送信トランスポートで同時に処理するメッセージを少なくする必要があることを示しています。 また、一度にいくつかのメッセージを処理すると効率性が向上するアダプター (コンカレント接続を制限しているサーバーに送信する場合など) を使用しているシナリオでは、このパラメーターは、既定値よりも小さい値に設定できることがあります。
この分析では、高 In-Process メッセージ数カウンターを調べて、この種類の調整が発生しているかどうかを判断します。 その場合は、"CPU あたりのインプロセス メッセージ数" 設定を調整することを検討してください。 このパラメーターは、送信メッセージの制限だけに影響します。 CPU あたりのインプロセス メッセージ数に基づいて調整を無効にするには、[CPU あたりのインプロセス メッセージ数] 設定に値 0 を入力します。 [IN-Process messages per CPU]\(CPU あたりのインプロセス メッセージ\) 設定の既定値は 1,000 です。 この値を変更すると、メッセージの待機時間の短縮や BizTalk リソースの効率にも影響を与える可能性があることに注意してください。
リファレンス
BizTalk のメッセージ配信率の高い分析
送信 (配信) メッセージの場合、ホスト インスタンスのメッセージ配信受信レートがメッセージ配信送信レート * 指定されたレート オーバードライブ係数 (パーセント) 値を超えた場合、BizTalk Serverはメッセージの配信を調整します。 rate overdrive factor (percent) パラメーターは、[メッセージ処理の調整設定] ダイアログ ボックスで構成できます。 送信メッセージのレートベースの調整は、主に、メモリ内キューからメッセージを削除する前に遅延を発生させ、処理のためにメッセージをエンド ポイント マネージャー (EPM) またはオーケストレーション エンジンに配信することによって実現されます。 送信メッセージのレートベースの調整を実現するために、他のアクションは実行されません。
送信制限ではメッセージの配信が遅れる場合があるため、メッセージがインメモリ キューに蓄積され、制限の条件が緩和されるまでキューから取り出すスレッドがブロックされる可能性があります。 キュー解除スレッドがブロックされている場合、送信配信のために MessageBox からメモリ内キューに追加のメッセージはプルされません。
この分析では、メッセージ配信率が高いカウンターで値 1 がチェックされます。 メッセージ配信率が高い場合は、処理の複雑さが高い、送信アダプターが遅い、またはシステム リソースが一瞬不足している可能性があります。
リファレンス
BizTalk High Process メモリ分析
BizTalk プロセス メモリ使用量調整しきい値設定は、1 ~ 100 の値が入力された場合に、プロセスで使用可能なワーキング セットサイズと使用可能な仮想メモリの合計と比較して使用されたメモリの割合です。 既定では、BizTalk プロセス メモリ使用量調整設定は 25 です。 比率が指定されている場合、プロセス メモリのしきい値は、定期的に再計算されます。 ユーザーがパーセンテージ値を指定した場合、コミットできるメモリと現在のプロセス メモリ使用量に基づいて計算されます。
この分析では、高プロセス メモリ カウンターで値 1 がチェックされます。 これが発生した場合は、Debug Diag を使用してメモリの増加の原因を特定してみてください (メモリ リーク検出分析のリファレンスを参照してください)。 プロセスが起動中に大量のメモリを消費するのは通常であり、これは最初はメモリ リークとして表示されますが、プロセスが不要になったメモリを解放できなかった場合に真のメモリ リークが発生するため、時間の経過と同時に使用可能なメモリの量が減ります。 BizTalk でプロセス メモリ リークを一般的に分析する方法の詳細については、PAL の「メモリ リーク検出」のリファレンスおよび/または「メモリ リーク検出」のリファレンスを参照してください。
発行するバッチにメモリ要件が急な場合や、メッセージを処理しているスレッドが多すぎる場合は、高いプロセス メモリ調整が発生する可能性があります。 システムが過剰に調整されている場合は、ホストのプロセス メモリ使用量のしきい値に関連付けられている値を増やすことを検討し、ホスト インスタンスで "メモリ不足" エラーが生成されないことを確認します。 プロセス メモリ使用量のしきい値を増やすことで "メモリ不足" エラーが発生した場合は、内部メッセージ キュー サイズとインプロセス メッセージの CPU しきい値あたりの値を減らすことを検討してください。 この方法は、サイズの大きいメッセージを処理するシナリオに特に関連します。 さらに、メッセージあたりのメモリ要件が大きいシナリオでは、この値を低い値に設定する必要があります。 低い値を設定すると、早い段階で調整が開始され、プロセス内でメモリが爆発するのを防ぐことができます。
BizTalk サーバーが定期的に仮想メモリを使い切る場合は、64 ビットBizTalk Server検討してください。 64 ビット サーバー上の各プロセスは、32 ビットの 2 GB に対して最大 4 TB の仮想メモリに対処できます。 一般に、64 ビット BizTalk と 64 ビット SQL Serverを強くお勧めします。 詳細については、「BizTalk Server 64 ビット サポート」リファレンスを参照してください。
リファレンス
BizTalk High System Memory Analysis
BizTalk 物理メモリ使用量調整しきい値設定は、1 から 100 までの値が入力された場合の使用可能な物理メモリの合計量に対するメモリ消費量の割合です。 100 より大きい値を入力した場合、この設定は使用可能な物理メモリの合計量をメガバイト単位で指定することもできます。 物理メモリ使用量に基づいた制限を無効にするには、値 0 を入力してください。 既定値は 0 です。
この分析では、高システム メモリ カウンターで値 1 がチェックされます。 すべてのシステム メモリが測定されるので、BizTalk Server 以外のプロセスが多くのシステム メモリを使用している場合に制限の条件が発生する可能性があります。 そのため、これが発生した場合は、最も多くの物理メモリを消費しているプロセスを特定したり、サーバーに物理メモリを追加したりするのが最善の方法です。 また、EPM スレッド プールの既定のサイズやアダプター バッチのサイズを小さくすることで、負荷を軽減することを検討してください。 詳細については、PAL でのメモリ リーク検出の分析に関するページを参照してください。
リファレンス
BizTalk のスレッド数の多い分析
"CPU あたりのスレッド数" は、アダプターによって使用されるスレッドを含む、ホスト プロセス内のスレッドの合計数です。 このしきい値を超えた場合、BizTalk Serverは EPM スレッド プールとメッセージ エージェント スレッド プールのサイズを小さくしようとします。 高負荷によって多くのスレッドを作成するシナリオでは、スレッド ベースの制限を有効にする必要があります。 このパラメーターは、受信制限と送信制限の両方に影響します。 スレッド ベースの調整は、既定では無効になっています。
注意
ユーザー指定の値がガイドラインとして使用され、ホストは、プロセスのメモリ使用パターンとスレッド要件に基づいて、このしきい値を動的に自己調整できます。
この分析では、高スレッド数カウンターで値 1 がチェックされます。 多くのスレッドが作成されないように、異なるスレッド プール サイズを設定することを検討します。 この分析は、1 秒あたりのコンテキスト スイッチ分析と関連付けて、オペレーティング システムが多すぎるスレッドで飽和しているかどうかを判断できますが、ほとんどの場合、スレッド数が多いと、BizTalk サーバーよりもバックエンド データベースで競合が多くなります。 スレッド プール サイズの変更の詳細については、「How to Modify the Default Host Throttling Settings in references」を参照してください。
リファレンス
-
BizTalk 受信待機時間の分析メッセージング エンジンがアダプターからドキュメントを受信してからメッセージ ボックスに発行されるまでの待機時間 (ミリ秒単位)。 BizTalk の一部のユーザーにとって待機時間の短縮は重要であるため、ドキュメントが受信アダプターに費やす時間を追跡することが重要です。
待機時間の測定方法を示すグラフを次に示します。
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| アダプターはメッセージを受信してエンジンに送信します。これらのパフォーマンス カウンターでキャプチャされていないエンジンにメッセージが渡される前にアダプターで実行された作業 | エンジンはアダプターからメッセージを受信し、受信パイプライン、マップ、サブスクリプション評価を実行し、DB でメッセージを保持します。 | オーケストレーションまたは Solicit-Response ポートが実行され、応答メッセージが生成されます。 | 応答メッセージはメッセージング エンジンでデキューされ、送信パイプラインを実行し、マップします。 | メッセージング エンジンは、アダプターに応答メッセージを送信します。 | アダプターは、エンジン メッセージがすべて完了したことを通知します。 |
| I | |||||
| Rr | Rr | Rr | |||
| O | O | O | |||
| OA | OA |
I = 受信待機時間
RR = 要求応答の待機時間
O = 送信待機時間
OA = 送信アダプターの待機時間
待機時間が短い環境であると仮定すると、この分析では、ドキュメントが受信アダプターで 5 秒を超えたかどうかを確認します。 これは、このホスト インスタンス内の受信アダプターを介したメッセージの転送の処理遅延を示している可能性があります。 このホスト インスタンスに複数の受信アダプターが存在する場合は、それらを独自のホストに分離して、待機時間が長い受信アダプターを決定することを検討してください。
リファレンス
BizTalk メッセージ配信調整状態分析
BizTalk メッセージ配信の調整状態は、調整の主要なインジケーターの 1 つです。 これは、システムがメッセージ配信を調整しているかどうかを示すフラグです (XLANG メッセージ処理と送信トランスポートに影響を与えます)。 調整条件は、カウンターの数値によって示されます。 値とそのそれぞれの意味の一覧を次に示します。
| 調整条件 | 説明 |
|---|---|
| 0 | 制限なし。 |
| 1 | メッセージ配信レートが不安定なことに起因する制限。入力率が出力率を超えています。 |
| 3 | インプロセス メッセージ カウントが大きいことに起因する制限。 |
| 4 | プロセス メモリ不足に起因する制限。 |
| 5 | システム メモリ不足に起因する制限。 |
| 9 | スレッド カウントが大きいことに起因する制限。 |
| 10 | 配信におけるユーザー オーバーライドに起因する制限 |
この分析では、これらの各値を確認し、それぞれの特定のアラートを取得します。
リファレンス
BizTalk MessageBox データベース接続エラーの分析
このパフォーマンス カウンターは、ホスト インスタンスの起動後に失敗した試行データベース接続の数です。 BizTalk データベースをホストしているSQL Server サービスが何らかの理由で使用できなくなった場合、データベース クラスターはアクティブ なコンピューターからパッシブ コンピューターにリソースを転送します。 このフェールオーバー処理中に BizTalk Server サービスのインスタンスがデータベース接続の障害を検出すると、自動的にデータベースの再接続が実行されます。 正常に動作しているデータベース コンピューター (先ほどまでパッシブ側であったコンピューター) が、フェールオーバーでリソースを引き継いだ後、データベース接続の処理を開始します。
DBNetLib (データベース ネットワーク ライブラリ) エラーは、BizTalk Server ランタイムが MessageBox データベースまたは管理データベースと通信できない場合に発生します。 この場合、例外をキャッチするBizTalk Serverランタイム インスタンスがシャットダウンし、1 分ごとにチェックにサイクルして、データベースが使用可能かどうかを確認します。 このトピックの詳細については、「リファレンス」セクションを参照してください。
クライアントがサーバーとの TCP/IP ソケット接続を開始した場合、通常、そのクライアントはサーバー上の特定ポートに接続し、一時的な (短期) TCP ポートまたは UDP ポートを経由してクライアントに応答するようサーバーに要求します。 Windows Server 2003 および Windows XP では、クライアント アプリケーションで使用されるエフェメラル ポートの既定の範囲は 1025 から 5000 です。 特定の条件下では、既定の範囲で使用可能なポートが使い果たされる可能性があります。 このトピックの詳細については、「リファレンス」セクションを参照してください。
この分析では、データベース接続エラーが発生した場合を確認します。 BizTalk はデータベースなしでは機能しないため、データベース接続エラーは重要です。 データベース接続エラーの原因が不明な場合は、以下に示す参照を検討するか、接続エラーの性質を判断するためにMicrosoft サポートにお問い合わせください。
リファレンス
BizTalk メッセージングの発行調整の状態分析
BizTalk メッセージ発行の調整状態は、調整の主要なインジケーターの 1 つです。 これは、システムがメッセージの発行を調整しているかどうかを示すフラグです (XLANG メッセージ処理と受信トランスポートに影響を与えます)。調整条件は、カウンターの数値によって示されます。 値とそのそれぞれの意味の一覧を次に示します。
| 調整条件 | 説明 |
|---|---|
| 0 | 制限なし。 |
| 2 | メッセージ公開レートが不安定なことに起因する制限。入力率が出力率を超えています。 |
| 4 | プロセス メモリ不足に起因する制限。 |
| 5 | システム メモリ不足に起因する制限。 |
| 6 | データベース サイズの増加に起因する制限。 |
| 8 | セッション カウントが大きいこと起因する制限。 |
| 9 | スレッド カウントが大きいことに起因する制限。 |
| 11 | 公開におけるユーザー オーバーライドに起因する制限 |
この分析では、これらの各値を確認し、それぞれの特定のアラートを取得します。
リファレンス
メモリ内に常駐する BizTalk オーケストレーション
ホスト インスタンスによって現在ホストされているオーケストレーション インスタンスの数。 メモリ内に存在するオーケストレーションの急増やバーストは正常と見なされる場合があります。増加傾向は、メモリ内のオーケストレーションの "山" を示している可能性があります。 BizTalk がメッセージ/オーケストレーション インスタンスを退避できない場合、時間の経過と同時に増加傾向が発生する可能性があります。 このカウンターを "XLANG/s Orchestrations(?) と関連付けようとします。疑問符 (?) がこのカウンターと同じカウンター インスタンスである \退避可能なオーケストレーション。
多数のオーケストレーションがメモリ内に存在し、オーケストレーションの数が少ない場合は、オーケストレーションがメモリ内でアイドル状態になり、メモリ リーク状態が発生する可能性があります。 この分析は、"\XLANG/s Orchestrations(*)\Idle orchestrations" (存在する場合) との相関関係で使用します。 BizTalk アイドル オーケストレーションの増加傾向は、オーケストレーション インスタンスを脱水できないためにメモリ リークを示す指標として優れています。
この分析では、メモリ内に存在するオーケストレーションの増加傾向が確認され、メモリ内に存在するオーケストレーションの 50% を超えるオーケストレーションが脱水不可能かどうかが確認されます。
リファレンス
BizTalk プライベート バイト分析
これは、ホスト インスタンスに割り当てられたプライベート メモリのメガバイトであり、"\Process(*)\Private Bytes" パフォーマンス カウンターに相当します。 Private Bytes は、他のプロセスと共有できないプロセスが割り当てたメモリの現在のサイズ (バイト単位) です。 この分析では、いずれかのホスト インスタンスがシステムのメモリの大きなサイズを消費しているかどうか、およびホスト インスタンスが時間の経過と共にメモリ消費量が増加しているかどうかを判断します。 メモリの大部分を消費するホスト インスタンスは、メモリがシステムに返される限り問題ありません。 グラフで増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。
この分析では、1 時間あたり 10 MB の増加傾向が確認されます。 この分析は、使用可能なメモリ分析とメモリ リーク分析との相関関係で使用します。 また、新しく開始されたホスト インスタンスは、単純に通常の起動動作である場合、最初はメモリ リークとして表示されることに注意してください。 メモリ リークとは、プロセスがメモリを消費し続け、長期間にわたってメモリを解放しない場合です。 メモリ リーク状態が疑われる場合は、以下の「BizTalk メッセージングでのメモリの増加」の記事を参照してください。 それ以外の場合は、Debug Diag ツールをインストールして使用します。 Debug Diag Tool の詳細については、「リファレンス」セクションを参照してください。
リファレンス
BizTalk 仮想バイト分析
これは、ホスト インスタンスの仮想メモリ用に予約されているメガバイトです。 この分析では、いずれかのホスト インスタンスがシステムのメモリを大量に消費しているかどうか、およびホスト インスタンスが時間の経過と共にメモリ消費量を増やしているかどうかを判断します。 メモリの大部分を消費するホスト インスタンスは、メモリをシステムに返す限り問題ありません。 グラフで増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。
この分析では、1 時間あたり 10 MB の増加傾向が仮想バイト単位で確認されます。 この分析は、使用可能なメモリ分析とメモリ リーク分析との相関関係で使用します。 また、新しく開始されたホスト インスタンスは、単純に通常の起動動作である場合、最初はメモリ リークとして表示されることに注意してください。 メモリ リークとは、プロセスがメモリを消費し続け、長期間にわたってメモリを解放しない場合です。 メモリ リーク状態が疑われる場合は、以下の「BizTalk メッセージングでのメモリの増加」の記事を参照してください。 それ以外の場合は、Debug Diag ツールをインストールして使用します。 Debug Diag Tool の詳細については、「リファレンス」セクションを参照してください。
リファレンス
BizTalk メッセージ エージェント データベース セッション調整の分析
これは、それぞれの BizTalk 調整設定と比較した MessageBox に対する開いているデータベース接続の数です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 ホストごとの一般的なセッション プールのアイドル状態のデータベース セッションは、この数に含まれません。また、この確認処理は、ホスト インスタンスによって実際に使用されるセッションの数に厳密に基づいて実行されます。 このオプションは、既定で無効です。通常、BizTalk Server システムでデータベース サーバーがボトルネックになる場合のみ、この設定を有効にする必要があります。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのデータベース セッション パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、送信メッセージの制限だけに影響します。 データベース セッションの数に基づいた制限を無効にするには、値 0 を入力してください。 既定値は 0 です。
MaxWorkerThreads レジストリ キーは、BizTalk で使用できるスレッド数に影響を与え、BizTalk のスレッドのほとんどがデータベース接続でビジー状態になっている場合に役立つ場合があります。 この分析では、MessageBox に対する開いているデータベース接続の数がデータベース セッション調整設定の 80% を超えるかどうかを確認し、調整条件が発生する可能性が高いことを示します。
リファレンス
BizTalk メッセージ エージェント データベース セッション調整しきい値の分析
これは、MessageBox に対する開いているデータベース接続の数の現在のしきい値です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 ホストごとの一般的なセッション プールのアイドル状態のデータベース セッションは、この数に含まれません。また、この確認処理は、ホスト インスタンスによって実際に使用されるセッションの数に厳密に基づいて実行されます。 このオプションは、既定で無効です。通常、BizTalk Server システムでデータベース サーバーがボトルネックになる場合のみ、この設定を有効にする必要があります。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのデータベース セッション パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、送信メッセージの制限だけに影響します。 データベース セッションの数に基づいた制限を無効にするには、値 0 を入力してください。 既定値は 0 です。
MaxWorkerThreads レジストリ キーは、BizTalk で使用できる数のスレッドに影響を与え、BizTalk のほとんどのスレッドがデータベース接続でビジー状態になっている場合に役立つ場合があります。 この分析では、この値が既定の設定から変更されているかどうかを確認します。 既定では、この設定は 0 です。これは、データベース セッションの調整が無効になっていることを意味します。
リファレンス
BizTalk メッセージ エージェントのインプロセス メッセージ数調整分析
これは、サービス クラスが処理している同時メッセージの数です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 これには、データベースから取得されたメッセージは含まれませんが、メモリ内キューでの配信を待機しています。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのインプロセス メッセージ数パフォーマンス カウンターを使用して、インプロセス メッセージの数を監視できます。 制限の条件を確認する制限メカニズムは、このパラメーターの値を参考にします。 実際のしきい値は、自律的に調整されます。 [In-process message count] パフォーマンス カウンターを監視して、実際のしきい値を確認できます。
大きなメッセージ シナリオ (平均メッセージ サイズが大きい場合、またはメッセージの処理に大量のメッセージが必要な場合) の場合は、このパラメーターを小さい値に設定できます。 大きなメッセージ シナリオでは、メモリベースの調整が頻繁に発生しすぎるかどうか、およびメモリしきい値が大幅に低い値に自動的に調整される場合が示されます。 このような結果は、過度のメモリ消費を避けるため、送信トランスポートで同時に処理するメッセージを少なくする必要があることを示しています。 また、一度にいくつかのメッセージを処理すると効率性が向上するアダプター (コンカレント接続を制限しているサーバーに送信する場合など) を使用しているシナリオでは、このパラメーターは、既定値よりも小さい値に設定できることがあります。 この分析では、[高 In-Process メッセージ数] カウンターを調べて、同じ名前で調整設定の 80% を超えるかどうかを判断します。これは、調整条件が発生する可能性があることを示します。
リファレンス
BizTalk:Message Agent のインプロセス メッセージ数調整しきい値分析
これは、サービス クラスが処理している同時メッセージの数の現在のしきい値です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 これには、データベースから取得されたメッセージは含まれませんが、メモリ内キューでの配信を待機しています。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのインプロセス メッセージ数パフォーマンス カウンターを使用して、インプロセス メッセージの数を監視できます。 制限の条件を確認する制限メカニズムは、このパラメーターの値を参考にします。 実際のしきい値は、自律的に調整されます。 [In-process message count] パフォーマンス カウンターを監視して、実際のしきい値を確認できます。
大きなメッセージ シナリオ (平均メッセージ サイズが大きい場合、またはメッセージの処理に大量のメッセージが必要な場合) の場合は、このパラメーターを小さい値に設定できます。 大きなメッセージ シナリオでは、メモリベースの調整が頻繁に発生しすぎるかどうか、およびメモリしきい値が大幅に低い値に自動的に調整される場合が示されます。 このような結果は、過度のメモリ消費を避けるため、送信トランスポートで同時に処理するメッセージを少なくする必要があることを示しています。 また、一度にいくつかのメッセージを処理すると効率性が向上するアダプター (コンカレント接続を制限しているサーバーに送信する場合など) を使用しているシナリオでは、このパラメーターは、既定値よりも小さい値に設定できることがあります。 この分析では、既定値以外の値の高い In-Process メッセージ数の調整しきい値を確認します。
リファレンス
BizTalk メッセージ エージェント プロセス メモリ使用量 (MB) 調整分析
これは、現在のプロセス (MB) のメモリ使用量です。 BizTalk プロセス のメモリ調整は、発行するバッチにメモリ要件が急激である場合、またはメッセージを処理しているスレッドが多すぎる場合に発生する可能性があります。 システムが過剰に調整しているように見える場合は、ホストのプロセス メモリ使用量のしきい値に関連付けられている値を増やすことを検討し、ホスト インスタンスで "メモリ不足" エラーが生成されないことを確認します。 プロセス メモリ使用量のしきい値を増やすことで "メモリ不足" エラーが発生する場合は、CPU しきい値あたりの内部メッセージ キュー サイズとインプロセス メッセージの値を減らすことを検討してください。 この方法は、サイズの大きいメッセージを処理するシナリオに特に関連します。
BizTalk サーバーで仮想メモリが定期的に不足している場合は、64 ビットBizTalk Server検討してください。 64 ビット サーバー上の各プロセスは、32 ビットの 2 GB に対して最大 4 TB の仮想メモリに対処できます。 一般に、64 ビット BizTalk と 64 ビット SQL Serverを強くお勧めします。 詳細については、「BizTalk Server 64 ビット サポート」リファレンスを参照してください。 この分析では、プロセス のメモリ使用量が、同じ名前のそれぞれの調整しきい値の 80% を超えているかどうかを確認します。 既定では、BizTalk プロセス メモリ使用量調整設定は、プロセスで使用できる仮想メモリの 25% です。 /3GB スイッチは、この設定には影響しません。
リファレンス
BizTalk:Message Agent プロセス メモリ使用量 (MB) 調整しきい値分析
これは、現在のプロセス (MB) のメモリ使用量の現在のしきい値です。 しきい値は、このプロセスで使用できる実際のメモリ量とそのメモリ消費パターンに応じて動的に調整される場合があります。 BizTalk プロセス のメモリ調整は、発行するバッチにメモリ要件が急激である場合、またはメッセージを処理しているスレッドが多すぎる場合に発生する可能性があります。 システムが過剰に調整しているように見える場合は、ホストのプロセス メモリ使用量のしきい値に関連付けられている値を増やすことを検討し、ホスト インスタンスで "メモリ不足" エラーが生成されないことを確認します。 プロセス メモリ使用量のしきい値を増やすことで "メモリ不足" エラーが発生する場合は、CPU しきい値あたりの内部メッセージ キュー サイズとインプロセス メッセージの値を減らすことを検討してください。 この方法は、サイズの大きいメッセージを処理するシナリオに特に関連します。
BizTalk サーバーで仮想メモリが定期的に不足している場合は、64 ビットBizTalk Server検討してください。 64 ビット サーバー上の各プロセスは、32 ビットの 2 GB に対して最大 4 TB の仮想メモリに対処できます。 一般に、64 ビット BizTalk と 64 ビット SQL Serverを強くお勧めします。 詳細については、「BizTalk Server 64 ビット サポート」リファレンスを参照してください。 この分析では、プロセス メモリ調整が既定値以外に設定されているかどうかを確認します。