PAL (ログのパフォーマンス分析) ツールは、パフォーマンス モニター カウンター ログ (任意の既知の形式) を読み取り、複雑だが既知のしきい値 (指定) を使用して分析します。 このツールは、重要なパフォーマンス カウンターをグラフィカルにグラフ化し、しきい値を超えたときにアラートをスローする HTML ベースのレポートを生成します。 しきい値は、もともとは、BizTalk Server を含む Microsoft 製品チームと Microsoft サポートのメンバーによって定義されたしきい値に基づいています。 このツールは従来のパフォーマンス分析に代わるものではありませんが、時間を節約するのに十分なパフォーマンス カウンター ログの分析を自動化します。 PAL ツール:
しきい値のパフォーマンス カウンター ログを分析します
大規模な Perfmon ログに対して役立ちます
しきい値を分析して BizTalk Server とオペレーティング システムのパフォーマンス カウンターのボトルネックを識別します
あらゆるパフォーマンス カウンターに対して分析を実行できる拡張可能
自身のカウンターを書く手助けとして使用できます
PAL は GitHub で無料でダウンロードできます。 これには Microsoft ログ パーサーが必要です。 ログ パーサーは、ログ ファイル、XML ファイル、CSV ファイルなどのテキスト ベースのデータだけでなく、Windows オペレーティング システム上の主要なデータ ソース (イベント ログ、レジストリ、ファイル システム、Active Directory® ディレクトリ サービスなど) への汎用クエリ アクセスを提供する、強力で汎用性の高いツールです。 このツールを使用して、大量のログ情報を照会することができます。 ログ パーサー ツールをダウンロードできます。
異なる言語でのパフォーマンス カウンター ログでの 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 でディスク パフォーマンスのボトルネックを検出する最も信頼性の高い方法は、応答時間を測定することです。 応答時間が保守的なしきい値である 0.025 (25 ミリ秒) を超える場合、ユーザーに影響を与える顕著なスローダウンとパフォーマンスの問題が発生している可能性があります。 詳細については、このトピックの論理/物理ディスクの読み取り/書き込み待機時間の分析を参照してください。 |
| ディスク: 論理ディスク転送/秒 | "ディスク転送/秒" は、ディスクに対する読み取りと書き込みの操作の速度です。 この分析のしきい値は、論理ディスクのいずれかが低応答時間 (I/O 操作の場合は 25 ミリ秒を超える応答時間) を示しているかどうかを確認します。 これが true の場合、1 秒あたりのディスク転送は 80 以上である必要があります。 そうでない場合は、ディスク アーキテクチャを調査する必要があります。 ディスク I/O の低下の最も一般的な原因は、SAN での LUN のオーバーロードです。 詳細については、このトピックの論理ディスク転送/秒を参照してください。 |
| ディスク: ロジカルディスク % の空き領域 | "% 空き領域" は、選択した論理ディスク ドライブ上の空き領域の合計に対する割合です。 使用可能なディスク ドライブ領域が 30% 未満になるまで、パフォーマンスは影響を受けません。 ディスク ドライブの 70% を使用すると、残りの空き領域はディスク ドライブの中心にあるディスクのスピンドルの近くに配置され、パフォーマンス レベルが低くなります。 空きディスク領域が不足すると、ディスクのパフォーマンスが低下する可能性があります。 |
| ディスク: プロセス IO データ操作/秒およびプロセス IO その他の操作/秒の分析 | これらのカウンターは、プロセスによって生成されたすべての I/O アクティビティをカウントして、ファイル、ネットワーク、およびデバイスの I/O を含めます。 これらの分析では、プロセスが 1 秒あたり 1,000 を超える I/O を実行しているかどうかを確認し、警告としてフラグを設定します。 これらの分析は、ディスク分析などの他の分析との相関関係で、どのプロセスが I/O アクティビティに関与する可能性があるかを判断するために最適に使用されます。 |
| メモリ: 使用可能なメモリ | この分析では、使用可能なメモリの合計が低いかどうかを確認します。警告は使用可能な 10% で、Critical は 5% で使用可能です。 警告は、1 時間あたり 10 MB の減少傾向が検出された場合にも警告されます。これは、今後のメモリ状態の可能性を示している可能性があります。 物理メモリが不足すると、特権モードの CPU とシステムの遅延が増加する可能性があります。 詳細については、このトピックの「使用可能なメモリアナリシス」を参照してください。 |
| メモリ: 空きシステム ページ テーブル エントリ | Free System Page Table Entries (PTE) は、現在システムで使用されていないページ テーブル エントリの数です。 システムが PTE を使い切っているかどうかを判断するために、この分析では、空き PTE が 5,000 個未満の場合、または空き PTE が 10,000 個未満で警告が発せられる場合を確認します。 PTE が十分に不足すると、システム全体のハングが発生する可能性があります。 また、/3GB スイッチを使用すると、無料 PTE の量が大幅に減少します。 詳細については、このトピックの「Free System Page Table Entries Analysis」を参照してください。 |
| メモリ: メモリ リーク検出 | この分析では、いずれかのプロセスがシステムのメモリを大量に消費しているかどうか、およびプロセスが時間の経過と同時にメモリ消費量が増加しているかどうかを判断します。 プロセスがメモリをシステムに返す限り、メモリの大部分を消費するプロセスは問題ありません。 グラフ内の増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。 "Private Bytes" は、他のプロセスと共有できない、このプロセスが割り当てたメモリの現在のサイズ (バイト単位) です。 この分析では、1 時間あたり 10 MB、増加傾向が 1 時間あたり 5 MB かどうかを確認します。 PAL の使用可能なメモリ分析との相関関係で、この分析を使用します。 詳細については、このトピックの「メモリ リーク検出分析」を参照してください。 |
| メモリ: ハンドルのリーク検出 | この分析では、すべてのプロセスをチェックして、開いているハンドルの数を判断し、ハンドル リークが疑われるかどうかを判断します。 ハンドルの数が多いプロセスや、積極的な上昇傾向があるプロセスは、ハンドル リークを示す可能性があり、通常はメモリ リークが発生します。 このプロセスによって現在開かれているハンドルの合計数は、このプロセスの各スレッドによって現在開かれているハンドルの合計と同じです。 リファレンス: デバッグ診断ツール |
| メモリ：メモリ ページ インプット率/秒 | "ページ入力/秒" は、ハード ページエラーを解決するためにディスクからページが読み取られた速度です。 ハード ページ エラーは、プロセスが、ワーキング セット内または物理メモリ内の他の場所にない仮想メモリ内のページを参照し、ディスクから取得する必要がある場合に発生します。 この分析では、1 秒あたり 10 を超えるページ ファイル読み取りがあるかどうかを確認します。 |
| Memory: メモリページ/秒 | この分析では、"Pages/sec" が高い (1,000 を超える) かどうかを確認します。 この値が高い場合は、メモリをディスクにページングしようとして、システムのメモリ不足が発生している可能性があります。 "Pages/sec" は、ハード ページエラーを解決するためにページがディスクから読み取られたりディスクに書き込まれたりする速度です。 このカウンターは、システム全体の遅延を引き起こす障害の種類の主要なインジケーターです。 この分析は、PAL の使用可能なメモリ分析とメモリ リーク検出分析との相関関係で使用します。 これらの分析がすべて同時にアラートをスローしている場合は、システムがメモリ不足と、関連する疑わしいプロセスを示し、PAL のメモリ リーク検出分析に記載されている分析手順に従っている可能性があります。 詳細については、このトピックのメモリ ページ/秒分析を参照してください。 |
| メモリ: メモリ システム キャッシュ常駐バイト数 | "System Cache Resident Bytes" は、ファイル システム キャッシュ内のページング可能なオペレーティング システム コードのサイズ (バイト単位) です。 この値には、現在の物理ページのみが含まれており、現在常駐していない仮想メモリ ページは含まれません。 この値は、現在物理メモリ内にあるすべてのページング可能なオペレーティング システム コードを表す "Memory\\System Code Resident Bytes" のコンポーネントです。 このカウンターには、最後に観察された値のみが表示されます。平均ではありません。 この分析では、1 時間あたり 10 MB の増加傾向が確認されます。 負荷が高い場合、サーバーはディスクなどの I/O アクティビティをキャッシュするためにシステム キャッシュを使用する場合があります。 PAL のプロセス IO データ操作/秒分析とプロセス IO その他の操作/秒分析との相関関係で使用します。 リファレンス: ファイル キャッシュのパフォーマンスとチューニング |
| メモリ: ノンページプールのバイト数 | “プール非ページド バイト”は、非ページド プールのサイズ (バイト単位) を指し、これはディスクに書き込むことができず、割り当てられている限り物理メモリに保持され続けなければならないオブジェクトのシステムメモリ領域です。 この分析では、システムがページングされていない最大プール のメモリ サイズに近づいているかどうかを確認します。 これを行うには、/3 GB、物理メモリ サイズ、32 ビット/64 ビットを考慮してプール サイズを見積もり、その値が推定プール サイズの 60% を超えているかどうかを判断します。 システムが最大サイズに近づくと、システム全体のハングが発生する可能性があります。 boot.ini ファイルの /3 GB スイッチ オプションを使用すると、このメモリ プールのサイズが大幅に削減されます。 詳細については、このトピックのプール非ページ バイト分析を参照してください。 |
| メモリ: プール のページ バイト数 | この分析では、システムがプールの最大ページング メモリ サイズに近づいているかどうかを確認します。 これを行うには、/3 GB、物理メモリ サイズ、32 ビット/64 ビットを考慮してプール サイズを見積もり、その値が推定プール サイズの 60% を超えているかどうかを判断します。 システムが最大サイズに近づくと、システム全体のハングが発生する可能性があります。 boot.ini ファイルの /3 GB スイッチ オプションを使用すると、このメモリ プールのサイズが大幅に削減されます。 詳細については、このトピック内のプールページバイト分析を参照してください。 |
| メモリ: プロセス スレッド数 | この分析では、すべてのプロセスをチェックして、プロセスに 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 使用率の高い原因となっている関数を分析することを検討してください。 |
| プロセッサのキューの長さ | この分析では、プロセッサ キューの平均長がプロセッサの数を超えているかどうかを判断します。 その場合は、プロセッサのボトルネックを示している可能性があります。 この分析は、PAL の特権モード CPU 分析とプロセスによる過剰なプロセッサ使用分析との相関関係で使用します。 詳細については、このトピックの「プロセッサ キュー長分析」を参照してください。 |
| プロセッサ: 特権モードの CPU 分析 | このカウンターは、スレッドが特権モードで実行される時間の割合を示します。 アプリケーションがオペレーティング システム関数 (ファイルまたはネットワーク I/O の実行やメモリの割り当てなど) を呼び出すと、これらのオペレーティング システム関数は特権モードで実行されます。 この分析では、特権モードの CPU が CPU 全体の 30% 以上を消費しているかどうかを確認します。 その場合、CPU 消費量は、ネットワーク、メモリ、ディスク I/O などのプロセッサ以外の別のボトルネックによって引き起こされる可能性があります。 プロセッサ:% 割り込み時間とプロセッサ:PALの高コンテキストスイッチング分析との相関関係で使用します。 詳細については、このトピックの「特権モードの CPU 分析」を参照してください。 |
| プロセッサ: 割り込み時間 | "% 割り込み時間" は、プロセッサがサンプル間隔中にハードウェア割り込みの受信とサービスに費やす時間です。 この値は、システム クロック、マウス、ディスク ドライバー、データ通信回線、ネットワーク インターフェイス カード、その他の周辺機器などの割り込みを生成するデバイスのアクティビティの間接的なインジケーターです。 これらのデバイスは、通常、タスクの完了時や注意が必要になったときにプロセッサを中断します。 通常のスレッド実行は割り込み中に中断されます。 ほとんどのシステムクロックは、プロセッサに 10 ミリ秒ごとに割り込みを発生させ、割り込み処理の背景を作成します。 このカウンターの大幅な増加は、ハードウェアの潜在的な問題を示しています。 この分析は、"% 割り込み時間" が 30%以上であることを確認します。 これが発生した場合は、このアラートに関連付けられるハードウェアのデバイス ドライバーを更新することを検討してください。 リファレンス: .NET Core で EventCounters を使用してパフォーマンスを測定する |
| プロセッサ: 頻繁なコンテキストスイッチング | コンテキストの切り替えは、優先度の高いスレッドが現在実行中の優先順位の低いスレッドよりも優先される場合、または優先度の高いスレッドがブロックされたときに発生します。 高レベルのコンテキスト切り替えは、多くのスレッドが同じ優先度レベルを共有している場合に発生する可能性があります。 これは、多くの場合、システム上のプロセッサに対して競合しているスレッドが多すぎることを示しています。 一般に、プロセッサあたり 5,000/秒未満のコンテキスト切り替え率は、心配する価値はありません。 コンテキスト切り替え速度がプロセッサあたり 1 秒あたり 15,000 を超える場合は、制約があります。 詳細については、このトピックの「高コンテキストスイッチング分析」を参照してください。 |
| Microsoft BizTalk Server: BizTalk 脱水オーケストレーション | 実行時間の長いビジネス プロセスが多数同時に実行されている場合は、メモリとパフォーマンスの問題が発生する可能性があります。 オーケストレーション エンジンは、オーケストレーション インスタンスを「ディハイドレート」および「リハイドレート」することで、これらの問題に対処します。 退避は、オーケストレーションの状態を SQL Server データベースにシリアル化するプロセスです。 リハイドレートは、オーケストレーションの最後の実行状態をデータベースから逆シリアル化するプロセスの逆です。 ディハイドレーションは、メモリ内で一度にインスタンス化する必要があるオーケストレーションの数を減らすことで、システムリソースの使用を最小限に抑えるために使用されます。 そのため、デハイドレートによってメモリ消費量は節約されますが、実行する操作は比較的コストがかかります。 この分析では、10以上の脱水状態を確認します。 その場合、BizTalk Server のメモリが不足している (仮想または物理)、多数のオーケストレーションがメッセージを待機しているか、退避設定が正しく設定されていない可能性があります。 リファレンス: オーケストレーションの脱水とリハイドレート |
| Microsoft BizTalk Server: BizTalk 多数のデータベースセッション | このカウンターには、標準 (0) または超過 (1) の 2 つの値があります。 この分析では、値 1 がチェックされます。 その場合、BizTalk は、許可されているデータベース セッションの数のしきい値を超えています。 この値は、BizTalk ホスト調整設定の "CPU あたりのデータベース接続数" の値によって制御されます。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのデータベース セッション パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、送信メッセージの制限にのみ影響を与えます。 詳細については、このトピックの BizTalk 高データベース セッション分析を参照してください。 |
| Microsoft BizTalk Server: BizTalk データベースサイズが大きい | このカウンターは、データベースしきい値のメッセージ数に関してリストされているいずれかの条件が発生した場合、値 1 に設定されます。 既定では、データベースのスロットリングしきい値におけるホストメッセージ数は 50,000 に設定されており、次の状況でスロットリングの条件が発動します。 - サブスクライブしているホストの作業キュー、状態キュー、および中断キューに対してホスト インスタンスによって発行されたメッセージの合計数が 50,000 を超えています。 - スプール テーブルまたは追跡テーブル内のメッセージの数が 500,000 メッセージを超えています。 これが発生した場合は、データベース内のメッセージの数を減らす一コースのアクションを検討してください。 たとえば、BizTalk Server の SQL Server ジョブがエラーなしで実行されていることを確認し、BizTalk Server 管理コンソールの [グループ ハブ] ページを使用して、メッセージの蓄積が多数の中断されたメッセージによって発生しているかどうかを判断します。 詳細については、このトピックの BizTalk 高データベース サイズ分析を参照してください。 |
| Microsoft BizTalk Server: BizTalk 高負荷 In-Process メッセージ数 | この分析では、高 In-Process メッセージ数カウンターを調べて、この種の制限が発生しているかどうかを判断します。 その場合は、"CPU あたりのIn-Process メッセージ数" 設定を調整することを検討してください。 このパラメーターは、アウトバウンドメッセージの制限にのみ影響します。 CPU あたりのインプロセス メッセージ数に基づく調整を無効にするには、「CPU あたりのIn-Process メッセージ数」設定に値 0 を入力します。 "CPU あたりのIn-Process メッセージ数" 設定の既定値は 1,000 です。 この値を変更すると、メッセージの待機時間の短縮や BizTalk リソースの効率に影響を与える可能性があることにも注意してください。 詳細については、このトピックの「BizTalk High In-Process Message Count Analysis」を参照してください。 |
| Microsoft BizTalk Server: BizTalk 高メッセージ配信率 | この分析では、高メッセージ配信率カウンターにおいて値 1 が確認されます。 メッセージ配信率が高い場合は、処理の複雑さが高い、送信アダプターが遅い、または一瞬のシステム リソース不足が原因である可能性があります。 詳細については、このトピックの BizTalk 高メッセージ配信率分析を参照してください。 |
| Microsoft BizTalk Server: BizTalk 高速メッセージ公開レート | 受信ホストの調整 (BizTalk Server でのメッセージ発行調整とも呼ばれます) は、メッセージをメッセージ ボックス データベースに発行する受信アダプターまたはオーケストレーションを含むホスト インスタンスに適用されます。 この分析では、高メッセージ発行率カウンターの値が1であることを確認します。 これが発生した場合、データベースは BizTalk MessageBox データベースへのメッセージの発行率に追いつくことができません。 参照： - ホストスロットリングのパフォーマンスカウンター - BizTalk Server でホスト調整を実装する方法 - レート制限の設定変更 - ホストの制限とは |
| マイクロソフト BizTalk サーバー: BizTalk プロセスメモリの使用量が高い | BizTalk プロセス メモリ使用量調整しきい値設定は、1 ~ 100 の値が入力された場合の、プロセスのワーキング セット サイズと使用可能な仮想メモリの合計と比較したメモリの割合です。 パーセンテージ値を指定すると、プロセス メモリのしきい値が一定の間隔で再計算されます。 この分析では、高プロセス メモリ カウンターの値が 1 かどうかを確認します。 詳細については、このトピックの BizTalk 高プロセス メモリ分析を参照してください。 |
| Microsoft BizTalk Server: BizTalk 高システムメモリ | BizTalk 物理メモリ使用量調整しきい値の設定は、1 ~ 100 の値が入力された場合の使用可能な物理メモリの合計量と比較したメモリ消費量の割合です。 100 より大きい値を入力した場合、この設定は使用可能な物理メモリの合計量をメガバイト単位で指定することもできます。 物理メモリの使用量に基づいた制限を無効にするには、0 を入力してください。 既定値は 0 です。 詳細については、このトピックの BizTalk 高システム メモリ分析を参照してください。 |
| 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 受信遅延 | メッセージング エンジンがアダプターからドキュメントを受信してから、メッセージ ボックスに発行されるまでの平均待機時間 (ミリ秒単位)。 BizTalk の一部のユーザーにとって待機時間の短縮は重要であるため、ドキュメントが受信アダプターに費やす時間を追跡することが重要です。 詳細については、このトピックの BizTalk 受信待機時間分析を参照してください。 |
| BizTalk Server: BizTalk メッセージ配信の遅延 | これは、各メッセージ配信バッチに課せられる現在の遅延 (ミリ秒単位) です (メッセージ配信が調整されている場合に適用されます)。 スロットリングに関しては、メッセージが受信か送信かに応じて、メッセージの発行または処理に遅延が適用されます。 遅延期間は、スロットリング条件の重大度に比例します。 重大度調整条件が高いほど、より低い重大度調整条件よりも長い調整期間が開始されます。 この遅延期間は、条件の変化に応じて調整メカニズムによって、特定の範囲内で上下に調整されます。 現在の遅延期間は、メッセージ配信遅延 (ms) と、BizTalk:Message Agent パフォーマンス オブジェクト カテゴリに関連付けられているメッセージ発行遅延 (ms) パフォーマンス カウンターによって公開されます。 この分析では、5 秒を超えるメッセージ配信遅延がチェックされます。 メッセージ配信の遅延が長くなる場合、負荷が高いために厳しい制限がかかっている可能性があります。 リファレンス: BizTalk Server がホスト調整を実装する方法。 |
| BizTalk Server: BizTalk メッセージ配信の調整状態 | BizTalk メッセージ配信の調整状態は、調整の主要なインジケーターの 1 つです。 これは、システムがメッセージ配信を調整しているかどうかを示すフラグです (XLANG メッセージ処理と送信トランスポートに影響します)。 調整条件は、カウンターの数値によって示されます。 詳細については、このトピックの「BizTalk メッセージ配信調整状態分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ発行の遅延 | メッセージの発行を調整するために、対象となる各バッチに挿入される遅延。 調整に関しては、メッセージが受信か送信かに応じて、メッセージの発行または処理に遅延が適用されます。 遅延期間は、スロットリング条件の深刻度に比例します。 重大度調整条件が高いほど、より低い重大度調整条件よりも長い調整期間が開始されます。 この遅延期間は、条件の変化に応じて調整メカニズムによって、特定の範囲内で上下に調整されます。 現在の遅延期間は、メッセージ配信遅延 (ms) と、BizTalk:Message Agent パフォーマンス オブジェクト カテゴリに関連付けられているメッセージ発行遅延 (ms) パフォーマンス カウンターによって公開されます。 この分析では、5 秒を超えるメッセージ発行の遅延がチェックされます。 メッセージ配信の遅延が長くなる場合、負荷が高いために厳しい制限がかかっている可能性があります。 リファレンス: BizTalk Server がホスト調整を実装する方法。 |
| BizTalk Server: BizTalk MessageBox データベース接続エラー | このパフォーマンス カウンターは、ホスト インスタンスの起動後に失敗したデータベース接続の試行回数です。 BizTalk データベースをホストしている SQL Server サービスが何らかの理由で使用できなくなった場合、データベース クラスターはアクティブなコンピューターからパッシブ コンピューターにリソースを転送します。 このフェールオーバー プロセス中に、BizTalk Server サービス インスタンスでデータベース接続エラーが発生し、自動的に再起動してデータベースに再接続します。 機能しているデータベース コンピューター (以前はパッシブ コンピューター) は、フェールオーバー中にリソースを想定した後、データベース接続の処理を開始します。 詳細については、このトピックの BizTalk MessageBox データベース接続エラー分析を参照してください。 |
| BizTalk Server: BizTalk メッセージングの待機時間: 要求応答の待機時間 | メッセージング エンジンがアダプターから要求ドキュメントを受信してから、応答ドキュメントがアダプターに返されるまでの平均待機時間 (ミリ秒)。 このトピックの BizTalk 受信待機時間分析での待機時間の測定方法を示すグラフを参照してください。 待機時間が短い環境を想定すると、この分析では、5 秒を超える Request-Response 待機時間がチェックされます。 これは、受信アダプターと送信アダプターの間の処理遅延を示している可能性があります。 参照： - 要求/応答メッセージング - ソリューションのスケーリング |
| 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 のLow-Latency シナリオの最適化 |
| BizTalk Server: BizTalk 保留中のメッセージ | メッセージ ボックスに受信したとして確認されていない受信メッセージの数。 保留中のメッセージは、メモリにプルされ、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) でエラーを発生させる可能性があります。 一般的な追跡データに加えて、追跡対象のメッセージが MessageBox データベースに蓄積され、ディスクのパフォーマンスが低下する可能性があります。 この分析では、追跡データ サイズで 1 時間あたり 5 MB を超える増加傾向が確認されます。 リファレンス: BizTalk 追跡データベースのアーカイブと消去 |
| BizTalk Server: BizTalk トランザクション スコープが中止されました | これは、ホスト インスタンスの起動後に中止された実行時間の長いスコープまたはアトミック スコープの数です。 トランザクション スコープの中止は、オーケストレーション内のトランザクション スコープで発生するエラーです。 スコープの補正ハンドラーは、スコープが正常に完了した場合にのみ呼び出されますが、(プロセスの後半でエラーが発生する可能性があるため) 周囲のスコープが中止することを決定したため、元に戻す必要があることを理解しておくことが重要です。 また、トランザクションが中止された場合、状態の "自動" ロールバックは発生しません。 この結果は、例外ハンドラーと補正ハンドラーを使用してプログラムで実現できます。 通常、トランザクション スコープの中止は運用環境では発生しません。そのため、この分析では、中止されたトランザクション スコープの発生を確認します。 リファレンス: トランザクション |
| BizTalk Server: BizTalk トランザクション スコープの補償 | 補正は、何らかのエラー状態に対応して正常にコミットされた作業を論理的に元に戻すと考えることができます。 スコープの補正ハンドラーは、スコープが正常に完了した場合にのみ呼び出されますが、(プロセスの後半でエラーが発生する可能性があるため) 周囲のスコープが中止することを決定したため、元に戻す必要があることを理解しておくことが重要です。 また、トランザクションが中止された場合、状態の "自動" ロールバックは発生しません。 これは、例外ハンドラーと補正ハンドラーを使用してプログラムで実現できます。 トランザクション スコープの補正は、運用環境では通常行うべきではありません。そのため、この分析では、中止されたトランザクション スコープの発生を確認します。 リファレンス: トランザクション |
| BizTalk Server: BizTalk 仮想バイト | これは、ホスト インスタンスの仮想メモリ用に予約されたメガバイトです。 この分析では、いずれかのホスト インスタンスがシステムのメモリを大量に消費しているかどうか、およびホスト インスタンスが時間の経過と同時にメモリ消費量を増やしているかどうかを判断します。 詳細については、このトピックの BizTalk 仮想バイト分析を参照してください。 |
| BizTalk Server: BizTalk Message Agent データベース セッションのスロットリング | これは、それぞれの BizTalk 調整設定と比較した、MessageBox への開いているデータベース接続の数です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 詳細については、このトピックの BizTalk メッセージ エージェント データベース セッション調整分析を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェント データベース セッションスロットリングしきい値 | これは、メッセージ ボックスへの開いているデータベース接続の数の現在のしきい値です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 詳細については、このトピックの「BizTalk メッセージ エージェント データベース セッション調整しきい値分析」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェントのインプロセス メッセージ数の制限 | これは、サービス クラスが処理している同時メッセージの数です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 詳細については、このトピックの「BizTalk Message Agent In-process Message Count Throttling Analysis」を参照してください。 |
| BizTalk Server: BizTalk メッセージ エージェントのインプロセス メッセージ数調整しきい値 | これは、サービス クラスが処理している同時メッセージの数の現在のしきい値です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 詳細については、このトピックの「BizTalk Message Agent In-process Message Count Throttling Threshold Analysis」を参照してください。 |
| 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 でディスク パフォーマンスのボトルネックを検出する最も信頼性の高い方法は、応答時間を測定することです。 応答時間が保守的なしきい値である 0.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 ツールをインストールして使用します。 デバッグ診断ツールの詳細については、「リファレンス」セクションを参照してください。
リファレンス
メモリ ページ/秒分析
この分析では、"Pages/sec" が高いかどうかを確認します。 この値が高い場合は、メモリをディスクにページングしようとして、システムのメモリ不足が発生している可能性があります。 "Pages/sec" は、ハード ページエラーを解決するためにページがディスクから読み取られたりディスクに書き込まれたりする速度です。 このカウンターは、システム全体の遅延を引き起こす障害の種類の主要なインジケーターです。 これは、"Memory\Pages Input/sec" と "Memory\Pages Output/sec" の合計です。 ページ数でカウントされるため、"Memory\Page Faults/sec" などの他のページ数と比較できます。
このカウンターは常に 1,000 未満である必要があります。 この分析では、1,000 を超す値がチェックされます。 この分析は、使用可能なメモリ分析とメモリ リーク検出分析との相関関係で使用します。 すべての分析が同時にアラートをスローしている場合、システムがメモリ不足であることを示している可能性があります。 このトピックの「メモリ リーク検出の分析に関する追加情報」で説明されている分析手順に従います。
リファレンス
メモリ システム キャッシュ常駐バイト分析
"System Cache Resident Bytes" は、ファイル システム キャッシュ内のページング可能なオペレーティング システム コードのサイズ (バイト単位) です。 この値には、現在の物理ページのみが含まれており、現在常駐していない仮想メモリ ページは含まれません。 タスク マネージャーに表示されるシステム キャッシュの値と同じです。 その結果、この値は、ファイル システム キャッシュで使用されている仮想メモリの実際の量よりも小さくなることがあります。 この値は、現在物理メモリ内にあるすべてのページング可能なオペレーティング システム コードを表す "Memory\\System Code Resident Bytes" のコンポーネントです。 このカウンターには、最後に観察された値のみが表示されます。平均ではありません。
この分析では、1 時間あたり 10 MB の増加傾向が確認されます。 負荷が高い場合、サーバーはディスクなどの I/O アクティビティをキャッシュするためにシステム キャッシュを使用する場合があります。 プロセス IO データ操作/秒分析とプロセス IO その他の操作/秒分析との相関関係で使用します。
プロセス別のプロセッサ使用率分析と過剰なプロセッサ使用率
"% プロセッサ時間" は、プロセッサが非アイドル スレッドの実行に費やす経過時間の割合です。 これは、アイドル状態のスレッドがサンプル間隔でアクティブになっている期間を測定し、その時間を間隔期間から減算することによって計算されます。 (各プロセッサには、他のスレッドを実行する準備ができていないときにサイクルを消費するアイドル 状態のスレッドがあります)。このカウンターは、プロセッサ アクティビティの主要なインジケーターであり、サンプル間隔中に観察されたビジー時間の平均パーセンテージを表示します。 これは、サービスが非アクティブな時間を監視し、その値を 100% から減算することによって計算されます。
この分析では、個々のプロセッサの使用率が 60% を超えるかどうかが確認されます。 その場合は、ユーザー モードの CPU が高いか、高い特権モードであるかを判断します。 高い特権モードの CPU が疑われる場合は、「特権モードの CPU 分析」を参照してください。 ユーザー モード プロセッサのボトルネックが疑われる場合は、プロセス プロファイラーを使用して、CPU 使用率の高い原因となっている関数を分析することを検討してください。 詳細については、「方法: 運用環境のサーバー アプリケーションの高ユーザー モード CPU ボトルネックの原因となっている関数を特定する」を参照してください。
プロセッサ キューの長さの分析
"プロセッサ キューの長さ" は、プロセッサ キュー内のスレッドの数です。 ディスク カウンターとは異なり、このカウンターには、実行中のスレッドではなく、準備完了のスレッドのみが表示されます。 複数のプロセッサを搭載したコンピューターでも、プロセッサ時間のキューは 1 つあります。 そのため、コンピューターに複数のプロセッサがある場合は、この値をワークロードにサービスを提供するプロセッサの数で除算する必要があります。 プロセッサあたり 10 スレッド未満の持続プロセッサ キューは、通常、ワークロードに依存して許容されます。
この分析では、プロセッサ キューの平均長がプロセッサの数を超えているかどうかを判断します。 その場合は、プロセッサのボトルネックを示している可能性があります。 この分析は、特権モードの CPU 分析とプロセス別の過剰なプロセッサ使用との相関関係で使用します。 プロセッサ キューは、別のアクティブなスレッドが現在実行されているため、準備はできてもプロセッサで実行できないスレッドのコレクションです。 プロセッサの数よりも多くのスレッドの持続的または定期的なキューは、プロセッサのボトルネックを示す適切な兆候です。
このカウンターを "Processor\% Processor Time" カウンターと組み合わせて使用して、アプリケーションがより多くの CPU を利用できるかどうかを判断できます。 マルチプロセッサ コンピューターでも、プロセッサ時間のキューは 1 つあります。 そのため、マルチプロセッサ コンピューターでは、"プロセッサ キューの長さ" (PQL) の値を、ワークロードにサービスを提供するプロセッサの数で除算します。
CPU が非常にビジー状態 (90% 以上の使用率) で、PQL 平均がプロセッサの数よりも一貫して高い場合は、追加の CPU の恩恵を受ける可能性があるプロセッサのボトルネックが発生する可能性があります。 または、アプリケーション レベルでスレッドとキューの数を減らすことができます。 これにより、コンテキストの切り替えが少なくなり、CPU の負荷を軽減できます。 CPU 使用率が低い高い PQL の一般的な理由は、プロセッサ時間の要求がランダムに到着し、スレッドがプロセッサに不規則な時間を要求するからです。 これは、プロセッサがボトルネックではないことを意味します。 改善が必要なのは、あなたのスレッド ロジックです。
ユーザー モード プロセッサのボトルネックが疑われる場合は、プロセス プロファイラーを使用して、CPU 使用率の高い原因となっている関数を分析することを検討してください。 詳細については、「方法: 運用環境のサーバー アプリケーションの高ユーザー モード CPU ボトルネックの原因となっている関数を特定する」を参照してください。
特権モードの CPU 分析
このカウンターは、スレッドが特権モードで実行される時間の割合を示します。 アプリケーションがオペレーティング システム関数 (ファイルまたはネットワーク I/O の実行やメモリの割り当てなど) を呼び出すと、これらのオペレーティング システム関数は特権モードで実行されます。
高い特権モードの CPU は、コンピューターがシステム I/O と実際の (ユーザー モード) の作業に多くの時間を費やしていることを示します。 "% Privileged Time" は、プロセス スレッドが特権モードでコードの実行に費やした経過時間の割合です。 Windows システム サービスが呼び出されると、多くの場合、サービスは特権モードで実行され、システム プライベート データにアクセスできるようになります。 このようなデータは、ユーザー モードで実行されているスレッドによるアクセスから保護されます。 システムへの呼び出しは、明示的なものや暗黙的なものとして、ページフォールトや割り込みなどがあります。 一部の初期のオペレーティング システムとは異なり、Windows では、ユーザーモードと特権モードの従来の保護に加えて、サブシステム保護にプロセス境界が使用されます。 アプリケーションに代わって Windows によって実行される作業の中には、プロセス内の特権時間に加えて、他のサブシステム プロセスにも表示される場合があります。
この分析では、特権モードの CPU が CPU 全体の 30% 以上を消費しているかどうかを確認します。 その場合、CPU 消費量は、ネットワーク、メモリ、ディスク I/O などのプロセッサ以外の別のボトルネックによって引き起こされる可能性があります。 % 割り込み時間と高コンテキストスイッチング分析との相関関係で使用します。
高度なコンテキスト切り替え分析
コンテキストの切り替えは、優先度の高いスレッドが現在実行中の優先順位の低いスレッドよりも優先される場合、または優先度の高いスレッドがブロックされたときに発生します。 高レベルのコンテキスト切り替えは、多くのスレッドが同じ優先度レベルを共有している場合に発生する可能性があります。 これは、多くの場合、システム上のプロセッサに対して競合しているスレッドが多すぎることを示しています。 プロセッサ使用率があまり表示されず、コンテキスト切り替えのレベルが非常に低い場合は、スレッドがブロックされていることを示している可能性があります。
高コンテキスト切り替えは、特権モードの CPU と全体的な CPU が高い場合にのみ調査する必要があります。 一般に、プロセッサあたり 5,000/秒未満のコンテキスト切り替え率は、心配する価値はありません。 コンテキスト切り替え速度がプロセッサあたり 1 秒あたり 15,000 を超える場合は、制約があります。
この分析では、高い CPU、高い特権モードの CPU、および高 (プロセッサあたり 5,000 を超える) システム コンテキスト スイッチが 1 秒あたりすべて同時に発生しているかどうかを確認します。 高コンテキストの切り替えが発生している場合は、システムで実行されているスレッドとプロセスの数を減らします。
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 を超えています。
スプール テーブルまたは追跡テーブル内のメッセージの数が 500,000 メッセージを超えています。
中断されたメッセージはデータベース計算のメッセージ数に含まれるため、BizTalk サーバーで負荷が低い場合や負荷が発生していない場合でも、メッセージの発行の調整が発生する可能性があります。
この分析では、値 1 がチェックされます。 これが発生した場合は、データベース内のメッセージの数を減らす一コースのアクションを検討してください。 たとえば、BizTalk SQL Server ジョブがエラーなしで実行されていることを確認し、BizTalk 管理コンソールのグループ ハブを使用して、メッセージの蓄積が多数の中断されたメッセージによって発生しているかどうかを判断します。
リファレンス
BizTalk High In-Process メッセージ数の分析
[ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 この数には、データベースから取得されたメッセージは含まれませんが、メモリ内キューでの配信を待機しています。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのインプロセス メッセージ数パフォーマンス カウンターを使用して、インプロセス メッセージの数を監視できます。 このパラメーターは、調整条件を検討するときの調整メカニズムにヒントを提供します。 実際のしきい値は、自己調整の対象となります。 インプロセス メッセージ数のパフォーマンス カウンターを監視することで、実際のしきい値を確認できます。
このパラメーターは、メッセージの平均サイズが大きい場合や、メッセージの処理に大量のメッセージが必要な場合がある、大きなメッセージ シナリオの場合は、小さい値に設定できます。 これは、シナリオでメモリベースの調整が頻繁に発生し、メモリしきい値が大幅に低い値に自動的に調整される場合に明らかです。 このような動作は、過剰なメモリ使用量を回避するために、送信トランスポートで同時に処理するメッセージが少なくなることを示します。 また、一度に数個のメッセージを処理する場合 (コンカレント接続を制限するサーバーに送信する場合など)、アダプターの効率が向上するシナリオでは、このパラメーターを既定値よりも小さい値に調整できます。
この分析では、高 In-Process メッセージ数カウンターを調べて、この種の制限が発生しているかどうかを判断します。 その場合は、"CPU あたりのIn-Process メッセージ数" 設定を調整することを検討してください。 このパラメーターは、アウトバウンドメッセージの制限にのみ影響します。 CPU あたりのインプロセス メッセージ数に基づく調整を無効にするには、「CPU あたりのIn-Process メッセージ数」設定に値 0 を入力します。 "CPU あたりのIn-Process メッセージ数" 設定の既定値は 1,000 です。 この値を変更すると、メッセージの待機時間の短縮や BizTalk リソースの効率に影響を与える可能性があることにも注意してください。
リファレンス
BizTalk 高メッセージ配信率分析
送信 (配信) メッセージの場合、BizTalk Server は、ホスト インスタンスのメッセージ配信受信レートがメッセージ配信の送信レート * 指定されたレート オーバードライブ係数 (パーセント) の値を超えた場合に、メッセージの配信を調整します。 レート オーバードライブ係数 (パーセント) パラメーターは、[メッセージ処理の調整設定] ダイアログ ボックスで構成できます。 送信メッセージのレートベースの調整は、主にメモリ内キューからメッセージを削除する前に遅延を誘発し、処理のためにメッセージをエンド ポイント マネージャー (EPM) またはオーケストレーション エンジンに配信することによって実現されます。 送信メッセージのレート制の制限を実現するために、他のアクションは実行されません。
送信制限によりメッセージの配信が遅れる可能性があり、メッセージがメモリ内キューに蓄積されることで、制限が解消されるまでデキュー・スレッドがブロックされる可能性があります。 キュー解除スレッドがブロックされると、メッセージ ボックスから送信配信用のメモリ内キューに追加のメッセージがプルされません。
この分析では、高メッセージ配信率カウンターにおいて値 1 が確認されます。 メッセージ配信率が高い場合は、処理の複雑さが高い、送信アダプターが遅い、または一瞬のシステム リソース不足が原因である可能性があります。
リファレンス
BizTalk 高プロセスメモリ分析
BizTalk プロセス メモリ使用量調整しきい値設定は、1 ~ 100 の値が入力された場合の、プロセスのワーキング セット サイズと使用可能な仮想メモリの合計と比較したメモリの割合です。 既定では、BizTalk プロセス メモリ使用量の調整設定は 25 です。 パーセンテージ値を指定すると、プロセス メモリのしきい値が一定の間隔で再計算されます。 ユーザーがパーセンテージ値を指定した場合、コミットできるメモリと現在のプロセス メモリ使用量に基づいて計算されます。
この分析では、高プロセス メモリ カウンターの値が 1 かどうかを確認します。 これが発生した場合は、Debug Diag を使用してメモリの増加の原因を特定してみてください (メモリ リーク検出分析のリファレンスを参照してください)。 プロセスが起動中に大量のメモリを消費するのは通常であり、これは最初はメモリ リークとして表示される可能性がありますが、プロセスが不要になったメモリを解放できない場合に真のメモリ リークが発生するため、時間の経過と同時に使用可能なメモリの量が減ります。 BizTalk でのプロセス メモリ リークを一般的に分析する方法の詳細については、以下の「メモリリークを引き起こしているプロセスのメモリ ダンプを取得する方法」に関するリファレンス、あるいはPAL の「メモリ リーク検出」の分析を参照してください。
発行するバッチのメモリ要件が急激な場合や、メッセージを処理しているスレッドが多すぎる場合は、高いプロセス メモリ調整が発生する可能性があります。 システムが過剰な調整を行っているように見える場合は、ホストのプロセス メモリ使用量のしきい値に関連付けられている値を増やすことを検討し、ホスト インスタンスが "メモリ不足" エラーを生成しないことを確認します。 プロセス メモリ使用量のしきい値を増やすことで "メモリ不足" エラーが発生した場合は、CPU しきい値あたりの内部メッセージ キュー サイズとインプロセス メッセージの値を減らすことを検討してください。 この戦略は、大規模なメッセージ処理シナリオで特に関連します。 さらに、メッセージごとにメモリ要件が大きいシナリオでは、この値を低い値に設定する必要があります。 低い値を設定すると、早い段階で調整が開始され、プロセス内でメモリが爆発するのを防ぐことができます。
BizTalk サーバーが定期的に仮想メモリを使い切る場合は、BizTalk Server 64 ビットを検討してください。 64 ビット サーバー上の各プロセスは、32 ビットの 2 GB に対して最大 4 TB の仮想メモリに対処できます。 一般に、64 ビットの BizTalk と 64 ビットの SQL Server を強くお勧めします。 詳細については、「BizTalk Server 64 ビット サポート」のリファレンスを参照してください。
リファレンス
BizTalk 高システムメモリ分析
BizTalk 物理メモリ使用量調整しきい値の設定は、1 ~ 100 の値が入力された場合の使用可能な物理メモリの合計量と比較したメモリ消費量の割合です。 100 より大きい値を入力した場合、この設定は使用可能な物理メモリの合計量をメガバイト単位で指定することもできます。 物理メモリの使用量に基づいた制限を無効にするには、0 を入力してください。 既定値は 0 です。
この分析では、高システム メモリ カウンターの値が 1 かどうかを確認します。 これによりシステム メモリの合計が測定されるため、BizTalk Server 以外のプロセスが大量のシステム メモリを消費している場合は、調整条件がトリガーされる可能性があります。 そのため、これが発生した場合は、最も多くの物理メモリを消費しているプロセスを特定したり、サーバーに物理メモリを追加したりするのが最善の方法です。 また、EPM スレッド プールの既定のサイズやアダプター バッチのサイズを小さくすることで、負荷を軽減することを検討してください。 詳細については、PAL のメモリ リーク検出分析を参照してください。
リファレンス
BizTalk 高スレッド数分析
"CPU あたりのスレッド数" は、アダプターによって使用されるスレッドを含む、ホスト プロセス内のスレッドの合計数です。 このしきい値を超えた場合、BizTalk Server は EPM スレッド プールとメッセージ エージェント スレッド プールのサイズを小さくしようとします。 負荷が高い場合に多数のスレッドが作成される可能性があるシナリオでは、スレッド ベースの調整を有効にする必要があります。 このパラメーターは、入出力制限の両方に影響します。 スレッドベースのスロットリングは、既定では無効になっています。
注
ユーザー指定の値がガイドラインとして使用され、ホストは、プロセスのメモリ使用パターンとスレッド要件に基づいて、このしきい値を動的に自己調整できます。
この分析では、高スレッド数カウンターで値 1 がチェックされます。 システムが多数のスレッドを作成しないように、さまざまなスレッド プール サイズを調整することを検討してください。 この分析は、1 秒あたりのコンテキスト スイッチ分析と関連付けて、オペレーティング システムが多すぎるスレッドで飽和しているかどうかを判断できますが、ほとんどの場合、スレッド数が多いと、BizTalk サーバーよりもバックエンド データベースで競合が多くなります。 スレッド プールのサイズを変更する方法の詳細については、参考資料の「既定のホスト調整設定を変更する方法」を参照してください。
リファレンス
-
BizTalk インバウンド レイテンシー分析: アダプターからメッセージング エンジンがドキュメントを受信してから、メッセージ ボックスに公開されるまでの平均レイテンシーをミリ秒単位で示します。 BizTalk の一部のユーザーにとって待機時間の短縮は重要であるため、ドキュメントが受信アダプターに費やす時間を追跡することが重要です。
待機時間の測定方法を示すグラフを次に示します。
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| アダプターはメッセージを受信し、エンジンに送信します。これらのパフォーマンス カウンターでキャプチャされていないエンジンにメッセージが渡される前にアダプターで行われた作業 | エンジンは、アダプターからメッセージを受信し、受信パイプラインを実行し、マップ、サブスクリプションの評価、DB でメッセージを保持します。 | オーケストレーションまたは Solicit-Response ポートが実行され、応答メッセージが生成されます。 | 応答メッセージはメッセージング エンジンでデキューされ、送信パイプラインを実行し、マップします。 | メッセージング エンジンは、アダプターに応答メッセージを提供します。 | アダプターは、エンジン メッセージがすべて完了したと通知します。 |
| 私 | |||||
| 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 ランタイムがメッセージ ボックスまたは管理データベースと通信できない場合に発生します。 この場合、例外をキャッチする 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 オーケストレーション（?）\退避可能なオーケストレーション」と関連付けてみてください。疑問符（?）はこのカウンターと同じカウンター インスタンスです。
多数のオーケストレーションがメモリに常駐し、しかも脱水可能なオーケストレーションの数が少ない場合は、オーケストレーションがメモリ内でアイドル状態になり、メモリリーク状態が発生する可能性があります。 この分析は、"\XLANG/s Orchestrations(*)\Idle orchestrations" (存在する場合) と相関して使用してください。 BizTalk のアイドル オーケストレーションが増加する傾向は、オーケストレーション インスタンスのデヒドラテーションができないことによるメモリリークのより明瞭な指標です。
この分析では、メモリ内に存在するオーケストレーションが増加傾向にあるかどうかをチェックします。また、メモリ内に存在するオーケストレーションが% の中で 50 を超える場合は、退避不可能な状態です。
リファレンス
BizTalk プライベート バイト解析
これは、ホスト インスタンスに割り当てられたプライベート メモリのメガバイト単位であり、"\Process(*)\Private Bytes" パフォーマンス カウンターに相当します。 プライベート バイトは、プロセスが割り当てたメモリの現在のサイズ (バイト単位) であり、他のプロセスと共有することはできません。 この分析では、いずれかのホスト インスタンスがシステムのメモリの大きなサイズを消費しているかどうか、およびホスト インスタンスが時間の経過と同時にメモリ消費量を増やしているかどうかを判断します。 メモリの大部分を消費するホスト インスタンスは、メモリをシステムに返す限り問題ありません。 グラフ内の増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。
この分析では、1 時間あたり 10 MB の増加傾向が確認されます。 この分析は、使用可能なメモリ分析とメモリ リーク分析との相関関係で使用します。 また、新しく開始されたホスト インスタンスは、単純に通常の起動動作である場合、最初はメモリ リークとして表示されることに注意してください。 メモリ リークとは、プロセスがメモリを消費し続け、長時間にわたってメモリを解放しない場合です。 メモリ リーク状態が疑われる場合は、以下の「BizTalk メッセージングでのメモリの増加」に関する記事を参照してください。 それ以外の場合は、Debug Diag ツールをインストールして使用します。 デバッグ診断ツールの詳細については、「リファレンス」セクションを参照してください。
リファレンス
BizTalk 仮想バイト分析
これは、ホスト インスタンスの仮想メモリ用に予約されたメガバイトです。 この分析では、いずれかのホスト インスタンスがシステムのメモリを大量に消費しているかどうか、およびホスト インスタンスが時間の経過と同時にメモリ消費量を増やしているかどうかを判断します。 メモリの大部分を消費するホスト インスタンスは、メモリをシステムに返す限り問題ありません。 グラフ内の増加傾向を探します。 長い期間にわたって増加傾向は、メモリ リークを示している可能性があります。
この分析では、仮想バイト数で 1 時間あたり 10 MB の増加傾向が確認されます。 この分析は、使用可能なメモリ分析とメモリ リーク分析との相関関係で使用します。 また、新しく開始されたホスト インスタンスは、単純に通常の起動動作である場合、最初はメモリ リークとして表示されることに注意してください。 メモリ リークとは、プロセスがメモリを消費し続け、長時間にわたってメモリを解放しない場合です。 メモリ リーク状態が疑われる場合は、以下の「BizTalk メッセージングでのメモリの増加」の記事を参照してください。 それ以外の場合は、Debug Diag ツールをインストールして使用します。 デバッグ診断ツールの詳細については、「リファレンス」セクションを参照してください。
リファレンス
BizTalk メッセージ エージェント データベース 接続制御分析
これは、それぞれの BizTalk 調整設定と比較した、MessageBox への開いているデータベース接続の数です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 共通のホストごとのセッション プール内のアイドル状態のデータベース セッションは、この数に追加されません。このチェックは、ホスト インスタンスによって実際に使用されているセッションの数に対して厳密に行われます。 このオプションは既定では無効になっています。通常、この設定は、データベース サーバーが BizTalk Server システムのボトルネックである場合にのみ有効にする必要があります。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリの下にあるデータベース セッション パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、アウトバウンドメッセージの制限にのみ影響します。 データベース セッションの数に基づいて調整を無効にするには、値 0 を入力します。 既定値は 0 です。
MaxWorkerThreads レジストリ キーは、BizTalk で使用できるスレッドの数に影響を与え、BizTalk のほとんどのスレッドがデータベース接続でビジー状態になっている場合に役立つ場合があります。 この分析では、MessageBox への開いているデータベース接続の数がデータベース セッション調整設定の 80% を超えるかどうかがチェックされ、調整条件が発生する可能性が高いと示されます。
リファレンス
BizTalk メッセージ エージェント データベース セッション制御しきい値の分析
これは、メッセージ ボックスへの開いているデータベース接続の数の現在のしきい値です。 "CPU あたりのデータベース接続数" は、調整が開始される前に許可される同時データベース セッション (CPU あたり) の最大数です。 共通のホストごとのセッション プール内のアイドル状態のデータベース セッションは、この数に追加されません。このチェックは、ホスト インスタンスによって実際に使用されているセッションの数に対して厳密に行われます。 このオプションは既定では無効になっています。通常、この設定は、データベース サーバーが BizTalk Server システムのボトルネックである場合にのみ有効にする必要があります。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリの下にあるデータベース セッション パフォーマンス カウンターを使用して、アクティブなデータベース接続の数を監視できます。 このパラメーターは、アウトバウンドメッセージの制限にのみ影響します。 データベース セッションの数に基づいて調整を無効にするには、値 0 を入力します。 既定値は 0 です。
MaxWorkerThreads レジストリ キーは、BizTalk で使用できるスレッドの数に影響を与え、BizTalk のほとんどのスレッドがデータベース接続でビジー状態になっている場合に役立つ場合があります。 この分析では、この値が既定の設定から変更されたかどうかを確認します。 既定では、この設定は 0 です。これは、データベース セッションでの調整が無効になっていることを意味します。
リファレンス
BizTalk メッセージ エージェントのプロセス内メッセージ数の調節分析
これは、サービス クラスが処理している同時メッセージの数です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 これには、データベースから取得されたメッセージは含まれませんが、メモリ内キューでの配信を待機しています。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのインプロセス メッセージ数パフォーマンス カウンターを使用して、インプロセス メッセージの数を監視できます。 このパラメーターは、調整条件を考慮する際のスロットル制御メカニズムに対してガイダンスを提供します。 実際のしきい値は、自己調整の対象となります。 インプロセス メッセージ数のパフォーマンス カウンターを監視することで、実際のしきい値を確認できます。
大きなメッセージ シナリオ (平均メッセージ サイズが大きい場合、またはメッセージの処理に大量のメッセージが必要な場合) の場合は、このパラメーターを小さい値に設定できます。 メモリベースのスロットリングが頻繁に発生し、メモリしきい値が非常に低い値に自動調整される場合、大きなメッセージのシナリオが示されます。 このような動作は、過剰なメモリ使用量を回避するために、送信トランスポートで同時に処理するメッセージが少なくなることを示します。 また、一度に数個のメッセージを処理する場合 (コンカレント接続を制限するサーバーに送信する場合など)、アダプターの効率が向上するシナリオでは、このパラメーターを既定値よりも小さい値に調整できます。 この分析では、High In-Process メッセージ数カウンターを調べて、それがそのスロットリング設定の 80% を超えているかどうかを判断します。これは、スロットリング状態が発生している可能性があることを示しています。
リファレンス
BizTalk: メッセージ エージェントプロセス内メッセージ数制限しきい値分析
これは、サービス クラスが処理している同時メッセージの数の現在のしきい値です。 [ホストの調整設定] の [CPU あたりのインプロセス メッセージ数] 設定は、処理されていないエンド ポイント マネージャー (EPM) または XLANG に配信されるメッセージの最大数です。 これには、データベースから取得されたメッセージは含まれませんが、メモリ内キューでの配信を待機しています。 BizTalk:Message Agent パフォーマンス オブジェクト カテゴリのインプロセス メッセージ数パフォーマンス カウンターを使用して、インプロセス メッセージの数を監視できます。 このパラメーターは、調整条件を考慮する際のスロットル制御メカニズムに対してガイダンスを提供します。 実際のしきい値は、自己調整の対象となります。 インプロセス メッセージ数のパフォーマンス カウンターを監視することで、実際のしきい値を確認できます。
大きなメッセージ シナリオ (平均メッセージ サイズが大きい場合、またはメッセージの処理に大量のメッセージが必要な場合) の場合は、このパラメーターを小さい値に設定できます。 メモリベースのスロットリングが頻繁に発生し、メモリしきい値が非常に低い値に自動調整される場合、大きなメッセージのシナリオが示されます。 このような動作は、過剰なメモリ使用量を回避するために、送信トランスポートで同時に処理するメッセージが少なくなることを示します。 また、一度に数個のメッセージを処理する場合 (コンカレント接続を制限するサーバーに送信する場合など)、アダプターの効率が向上するシナリオでは、このパラメーターを既定値よりも小さい値に調整できます。 この分析では、既定値以外の値に対する In-Process メッセージ数のスロットリングしきい値をチェックします。
リファレンス
BizTalk メッセージ エージェント プロセス メモリ使用量 (MB) スロットリング分析
これは、現在のプロセス (MB) のメモリ使用量です。 BizTalk プロセスのメモリ調整は、発行するバッチにメモリ要件が急激に存在する場合、またはメッセージを処理しているスレッドが多すぎる場合に発生する可能性があります。 システムが過剰な調整を行っているように見える場合は、ホストのプロセス メモリ使用量のしきい値に関連付けられている値を増やすことを検討し、ホスト インスタンスが "メモリ不足" エラーを生成しないことを確認します。 プロセス メモリ使用量のしきい値を増やすことで "メモリ不足" エラーが発生した場合は、CPU しきい値あたりの内部メッセージ キュー サイズとインプロセス メッセージの値を減らすことを検討してください。 この戦略は、大規模なメッセージ処理シナリオで特に関連します。
BizTalk サーバーが定期的に仮想メモリを使い切る場合は、BizTalk Server 64 ビットを検討してください。 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 サーバーが定期的に仮想メモリを使い切る場合は、BizTalk Server 64 ビットを検討してください。 64 ビット サーバー上の各プロセスは、32 ビットの 2 GB に対して最大 4 TB の仮想メモリに対処できます。 一般に、64 ビットの BizTalk と 64 ビットの SQL Server を強くお勧めします。 詳細については、「BizTalk Server 64 ビット サポート」のリファレンスを参照してください。 この分析では、プロセス メモリ調整が既定値以外に設定されているかどうかを確認します。